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ABSTRACT 


An  experimental  system  for  automatically  generating  certain  simple  kinds  of  programs  is 
described.  The  programs  constructed  are  expressed  in  a  subset  of  ALGOL  containing 
assignments,  function  calls,  conditional  statements,  while  loops,  and  non-recursive 
procedure  calls.  The  input  is  an  environment  of  primitive  programs  and  programming 
methods  specified  in  a  language  currently  used  to  define  the  semantics  of  the  output 
programming  language.  The  system  has  been  used  to  generate  programs  for  symbolic 
manipulation,  robot  control,  every  day  planning,  and  computing  arithmetical  functions. 
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INTRODUCTION 


1.  INTRODUCTION. 

We  present  an  experimental  system  for  writing  certain  simple  kinds  of  programs 

automatically.  The  system  requires  as  input  a  programming  environment  consisting, 
roughly  speaking,  of  primitive  functions  and  procedures,  rules  of  composition  and 
logical  facts  If  it  is  then  given  a  problem  it  attempts  to  find  a  method  of  solution  in 
terms  of  these  rules  and  primitives.  It  will  take  account  of  certain  kinds  of  advice  .from 
the  user  Some  of  the  techniques  it  uses  are  most  decidedly  heuristic  .  If 
successful  the  system  will  output  the  method  of  solution  in  the  form  of  a  plan  or 

Droeram  in  a  language  somewhat  similar  to  a  subset  of  Algol  containing 

assignments,  function  calls,  conditional  branches,  while  loops,  and  non-recursive 
procedure  calls.  We  call  this  language  the  OUTPUT  i  or  PROGRAM)  language.  The 
form-  of  the  definitions  of  the  elements  of  the  programming  environment  (i.e.  the 
primitive  procedures  and  rules  of  composition)  correspond  to  axioms  and  rules  of 
inference  in  a  logic  of  programs  currently  used  to  define  the  semantics  of  the 

programming  language  Pascal  [Hoare  1  969,  Hoare  and  Wirth  1972;  see  also  Igarashi, 
London,  Luckham  1973],  For  example  rules  for  constructing  while  loops  have  a  form 
corresponding  to  the  iteration  rule.  The  contents  of  these  definitions  vary  with  the 
actual  Environment.  Thus,  the  system  can  be  used  to  generate  simple  Algol- ike 
programs  for  robot  control  problems,  for  every-day  planning,  or  ,or  computing 
arithmetical  functions. 

Given  a  programming  environment  (from  now  on,  often  called  a  FRAME),  problems  to  be 
solved  are  stated  as  pars  of  conditions,  the  initial  input  condition  and  the  goal  output 
condition.  We  may  regard  these  pairs  as  the  input-output  assertions  of  ormulas  in 
the  logic  of  programs  referred  to  above.  The  system  is  presented  with  an 
Incomplete  formula  (i.e.  a  program  part  that  satisfies  the  input-output 
assertions  is  missing),  and  its  job  is  to  complete  the  formula  The  construction  of  a 
solution  program  may  therefore  be  formulated  as  a  search  for  a  proof  in  the  logic 
of  programs  of  a  theorem  whose  input-output  assertions  match  those  of  he 
incomplete  problem  formula.  This  enables  us  to  justify  the  forma  methods  of  he 

system  ^as  opposed  to  the  actual  implementation)  by  snowing  that  the  frrmal  methods 
will  always  construct  correct  programs. 

The  basic  component  that  does  most  of  the  searching  is  a  very  simple  backtrack 
problem  reduction  algorithm.  It  recursively  applies  to  a  given  goal  the  primitives  and 
rules  of  the  programming  environment  L  generate  subgoals  whose  solution  will  imply  a 
solution  to  the  goal.  It  proved  necessary  to  use  some  of  the  logical  facts  of 
the  programming  environment  in  special  ways  to  evoke  procedures  fcr  restricting 
the  growth  of  the  subgoal  tree.  This  is  often  referred  to  as  building  in  knowledge. 
In  this  case,  this  ied  to  a  few  rather  unusual  complexities  in  the  primitive 
language  we  have  for  Defining  the  environment,  which  we  call  the  FRAME 
language  The  choice  of  special  facts,  as  it  stands  at  the  moment,  was  very  much 
influenced  by  our  original  aim  to  study  autonomous  robot  planning,  i  he  set  of  these 
facts  is  not  dependant  on  the  environment  but  it  probably  should  be.  The  point 
is  that  the  definition  of  a  programming  environment  requires  not  onb'  the 
definitions  of  primitive  procedures,  rules  of  composition  and  logical  facts,  but  also 
some  additional  information  about  the  relations  in  the  environment  as  well.  This 
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information  to  some  extent  guides  the  problem-solving  behavior.  The  basis  of  the 
frame  language  is  a  free  variable  first  order  logic  in  which  statements  may  have  one 
of  three  truth  values  (TRUE,  FALSE,  and  UNDETERMINED). 

In  addition  to  the  special  logical  facts,  certain  statements  about  the  action  of  the 
problem  solver  itself  are  useful  in  reducing  the  search.  These  are  statements  such 
as  "when  an  attempt  at  goal  A  fails,  do  goal  B  before  reattempting  A"  or  "try  the 
procedure  FLY  before  the  procedure  WALK";  their  usefulness  usually  varies  from 
problem  to  problem  within  a  given  frame.  We  have  therefore  chosen  not  to  allow 
such  statements  within  the  frame  language,  but  to  develop  a  separate  ADVICE 
language  for  them.  Advice  can  be  given  to  the  system  interactively  while  it  is 
attempting  to  produce  a  program.  The  kind  of  advice  that  can  bo  expressed  at  the 
moment  is  very  elementary  and  is  not  specialized  towards  any  particular  domain  of 
program  generation.  The  function  of  advice  is  to  impose  structure  on  the  frame  (more 
accurately,  preference  and  relevance  connections  between  the  rules  and  axioms). 

Certainly  the  class  of  programs  that  this  system  will  construct  given  only  input-output 
specifications  depends  on  the  extensiveness  of  the  frame.  If  the  frame  contains  enough 
primitives  and  rules  (  one  might  call  these  programming  methods)  and  logical  facts,  the 
system  ought  to  enable  a  user  to  program  a  solution  to  a  problem  without  having  to 
give  much  "thought  in  advance  to  detailed  methodology  Thus  one  of  our  examples  of 
generated  programs  (Section  3)  is  the  very  simple  Fibonacci  program  suggested  in 
[Balzer  1  972]  as  an  example  of  what  automatic  programming  systems  ought  to  try 
to  do.  Admittedly,  our  frame  input  isn’t  quite  so  informal,  but  it  could  easily  be 
extended  to  accept  the  recurrence  equation  input  suggested  in  [Balzer  1972];  this 
could  be  translated  into  an  iterative  rule  in  the  frame  by  straightforward  methods 
(even  the  standard  algorithm  for  translating  linear  recursive  definitions  to  iterative  form 
would  do). 


Figure  1.  Main  System  Components 
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At  run  time  the  first  action  of  the  system  is  to  translate  a  given  frame  into  a 
backtrack  problem  solver  augmented  by  special  search  procedures.  If  advice  is 
given  during  a  search  for  a  solution  (i.e.  during  the  program  generation  phase)  the 
translator  is  called  and  the  problem  solver  is  modified.  If  a  solution  program  is  found, 
the  user  is  faced  with  a  number  of  choices.  He  can  ask  for  another  program  which 
takes  the  output  conditions  of  the  solution  as  its  input  conditions;  programs  can  thus 
be  constructed  in  segments  that  "fit  together".  He  can  choose  to  have  the 
solution  optimized  according  to  some  very  trivial  criteria,  or  generalized  and  placed 
on  a  library  of  nonprimitive  procedures.  If  the  solution  program  contains  conditional 
branches  calling  other  procedures,  he  can  choose  to  have  those  secondary 
procedures  constructed.  Eventually  he  may  choose  to  stop.  Figure  1  shows  the 
main  components  of  the  system  and  how  they  interact.  We  have  begun  to  make 
some  other  additions,  for  example,  the  ability  to  assume  the  existence  of  non¬ 
primitive  procedures,  in  order  to  try  the  system  as  an  interactive  aid  to 
structured  programming.  The  system  is  implemented  in  LISP  using  the  primitives 
and  backtracking  facilities  of  MicroPlanner  [Hewitt  1971,  Sussman  and  Winograd 
1 972.]  In  the  following  sections  we  have  tried  to  say  what  the  various 

components  of  the  system  do  without  going  into  too  many  details  of  how.  Most  of 
the  algorithms  are  quite  straightforward  so  it  does  seem  possible  to  do  this. 
Wherever  we  omit  discussion  of  special  tricks,  or  inadequacies  in  the 
implementation  languages  force  restrictions  upon  us,  we  try  to  leave  a  warning. 
Details  of  the  actual  implementation  are  given  in  [Buchanan  1974], 

We  assume  that  the  reader  is  familiar  with  the  usual  notation  and  terminology  of 
first  order  logic  and  also  with  some  straightforward  concepts  from  the  theory  of 
subgoaling  and  tree  searching  that  are  explained  in  [Nilsson  1971],  In  addition  we 
rely  on  (i.e.  use  without  defining)  some  of  the  concepts  of  backtrack 
programming  which  have  attained  fairly  standard  usage  in  many  papers,  and  may  be 
found  in  [Hewitt  1971,  Sussman  and  Winograd,  1972],  The  interest  in  applications 
to  ;  obot  planning  is  manifest  in  our  use  of  concepts  such  as  FLUENT  and  NON- 
FLJENT  etc.,  to  be  found  in  [McCarthy  and  Hayes  1  969]. 

Section  2  presents  an  overview  of  the  program  generation  system,  and  introduces 
some  of  the  questions  dealt  with  in  later  sections.  A  brief  outline  of  the  logic  of 
programs  is  given  and  it  is  shown  how  frame  definitions  and  the  program  construction 
rules  of  the  system  may  be  formulated  within  this  logic.  An  example  of  a  frame 
and  problem  is  given.  We  indicate  how  a  successful  subgoal  search  for  a  solution  may 
be  converted  into  a  proof  within  the  logic  of  programs  that  the  output  program 
solves  the  given  problem.  At  this  point  we  give  a  sketch  of  how  correctness 
proofs  may  be  constructed  in  general. 

Section  3  describes  the  language  for  frame  definitions,  the  advice  language  and  the 
output  program  language  Details  of  features  o!  the  system  are  given  in  the  following 
sections:  Section  4  provides  a  brief  description  of  how  the  various  problem  solving 
and  program  generation  processes  use  the  extra  facts  provided  in  a  frame 
definition,  evaluation  of  LISP  functions,  and  advice  from  the  user.  The  methods  for 
constructing  conditional  statements  are  given  in  Section  5,  and  for  constructing 
iterative  loops  in  Section  6.  Section  7  illustrates  how  simple  facilities  of  this 
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present  system  can  be  used  to  develop  complicated  programs  in  structured  steps. 
Illustrative  examples  of  frames  and  generated  programs  are  given  in  Sections  3,  5,  6 
and  7,  and  the  appendix  contains  a  complete  interactive  session. 

This  present  system  can  be  extended  at  many  points.  These  include  adding  new 
kinds  of  frame  rules  (for  constructing  recursive  procedures,  co-routines  etc.), 
and  improving  the  implementation  facilities,  the  interactive  system,  and  the 
problem  solver.  There  are  many  other  problem  domains  beyond  those  presented  in 
this  paper  where  the  possibility  of  using  the  present  system  to  generate 
procedures  for  solving  problems  exists.  For  example,  its  application  to  generating 
assembly  and  repair  programs  for  simple  machinery  is  illustrated  in  [l.uckham  and 
Buchanan,  1974],  At  some  point  in  these  developments  it  will  certainly  pay  to 
construct  specialized  systems  for  particular  classes  of  frames.  Additional  special 
features  common  to  frames  in  each  class  can  be  then  used  as  built-in  assumptions  to 
speed  up  the  problem  solver,  make  the  frame  and  advice  languages  more  natural, 
and  build  up  the  program  library. 

What  has  been  demonstrated  thus  far  by  the  system  presented  here  is  (i)  the 
current  axiomatic  theory  of  defining  the  semantics  of  programming  languages  can 
be  used  with  slight  modifications  to  define  many  other  simple  but  useful  problem 
environments;  (ii)  there  are  straight-forward  techniques  tar  translating  declarative 
descriptions  into  procedural  descriptions  for  problem  solving;  (iii)  standard  problem¬ 
solving  methods  can  be  used  to  synthesize  programs  in  a  structured  way  on  the 
basis  of  given  specifications,  and  to  handle  some  burdensome  details. 
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We  bepin  by  describing  how  frames  and  the  program  construction  methods  of  the 
system  can  be  formulated  within  the  Logic  of  Programs.  The  soundness  of  frames  and 
correctness  of  programs  are  discussed.  A  brief  description  of  the  underlying  problem- 
solving  algorithm  of  the  system  is  given.  We  then  outline  proofs  that  under  certain 
assumptions  the  programs  constructed  by  the  system  will  be  correct  The  presentation 
here  is  intended  to  be  informal  and  to  serve  as  an  introduction  to  the  later 
sectionsirnany  details  are  left  unmentioned  until  later,  and  statements  of  the  correctness 
results  are  weaker  and  more  restricted  than  they  need  be.  Extensions  of  the 
correctness  proof  are  discussed  in  later  sections. 

NOTATION:  x,y,z,u,v,w  ..variables, 

X,Y,Z,...  lists  of  variables, 

f,g,h„„  functions, 

S|t,..  functional  terms, 


G,I,P,Q,R,S,„.  Boolean  expressions  (essentially  formulas  of  first  order  logic 
’with'  standard  functions  and  predicates  for  equality,  numbers,  lists 

and  other  data  types),  . 

P(X)  denotes  the  formula  obtained  by  replacing  each  free  variable  in  P  by 

a  new  variable  from  X, 

(3X)P(X)  denotes  existential  quantification  over  all  X-variables  in  P(X), 


A,B.C,...  programs  and  program  parts  in  an  Algol-like  plan  language  (details 
in  Section  3), 


p,q,.,.  procedure  names, 

substitutions  of  terms  for  variables,  also  denoted  by  (<x<-t>). 
P(t)  denotes  the  result  of  replacing  x  by  t  everywhere  in  P(x). 


cv/3  denotes  the  COMPOSITION  of  *  and  / 3;  Eoc/3  =(E*)/3  for  all 
expressions  E. 


We  assume  the  existence  or  a  fixed  arbitrary  ordering  of  literals  (atoms  and  negations 
of  atoms). 


2.1  LOGIC  OF  PROGRAMS 


We  review  briefly  the  elements  of  an  inference  system  for  proving  properties  of 
programs  [Hoare  i  969].  Further  details  may  be  found  in  [Igarashi,  London,  Luckham 

1973], 


STATEMENTS  of  the  logic  are  of  three  kinds: 

v. 

(i)  Boolean  expressions,  (henceforth  often  called  ASSERTIONS) 


. . .  -  ■  ■  -i  (limmHhirtn.ri'i  i  , 
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(jj)  statements  of  the  form  P{A}Q  where  P,Q  are  Boolean  expressions  and  A  is  a 
program  or  program  part. 

P{A}Q  means  "if  P  is  true  of  the  input  state  and  A  halts  (or  halts  normally  in  the 
case  that  A  contains  a  GO  TO  to  a  label  not  in  A)  then  Q  is  true  of  the  output 
state". 

(iii)  Procedure  declarations,  p  PROC  K  where  p  is  a  procedure  name  and  K  is  a 
program  (the  body  of  p). 

A  RULE  OF  INFERENCE  is  a  transformation  rule  from  the  conjunction  of  a  set  of 
statements  (premisses,  say  H,  ,...,Hn )  to  a  statement  (conclusion,  say  K)  of  kind  (ii).  Such 

rules  are  denoted  by 


K 

The  concept  of  PROOF  in  the  logic  of  programs  is  defined  in  the  usual  way  as  a 
sequence  of  statements  that  are  either  axioms  or  obtained  from  previous  members  of 
the  sequence  by  a  rule.  A  proof  sequenca  is  a  proof  of  its  end  statement. 

NOTATION:  We  use  H  ||-  K  to  denote  that  K  can  be  proved  by  assuming  H.  H  |-  K 
denotes  the  same  thing  for  first  order  logic.  It  is  sometimes  helpful  to  denote 
statements  that  are  problems  or  subproblems  for  the  program  generator  to  solve  by 

P<?}Q. 

2.2  FRAMES  AND  PROBLEMS 

We  restrict  our  discussion  to  problems  that  can  be  represented  in  the  following  general 
form. 

The  problem  representation  consists  of  two  elements: 

(1)  F  -  a  set  of  rules  (or  laws)  called  the  ENVIRONMENT  (or  FRAME) 

(2)  The  problem,  which  is  a  pair  <I,G>: 

I  -  an  input  assertion  (or  initial  state). 

G  -  output  assertion  (or  goal). 

The  RULES  in  F  are  of  at  least  three  kinds: 

(a)  PROCEDURES:  transforming  states  into  states; 

(b)  SCHEMES:  methods  for  constructing  programs; 
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(c)  RELATIONAL  LAWS:  definitions  and  axioms  which  hold  In  all  states  and  serve  to 
"complete"  incomplete  state  descriptions  by  permitting  deduction  of  other 
elements  of  a  state  from  those  given. 

The  PROBLEM  is  the  problem  of  transforming  I  into  G  using  the  rules  of  F.  A  SOLUTION 
is  a  sequence  of  rules  that  transforms  I  to  G. 

REMARKS: 

1.  For  the  purposes  of  discussing  the  present  system  we  can  make  the  following 
restrictions: 

(i)  The  language  of  assertions  is  very  similar  to  Algol  Boolean  Expressions  (as 
referred  to  above). 

(ii)  Procedure  rules  and  schemes  are  expressed  as  statements  and  as  rules  of 
inference  (respectively)  in  the  logic  of  programs. 

(iii)  The  underlying  logic  of  the  relational  laws  is  first  order  logic. 

(iv)  The  logic  of  the  procedures  and  schemes  is  the  logic  of  programs. 

2.  We  probably  ought  to  permit  other  kinds  of  rules  in  F,  e.g.  rules  for  evaluating 
states,  comparing  states  etc. 

NOTATION  and  RESTRICTIONS:  Q  U  F  3  R  denotes  that  R  is  a  logical  consequence  of  Q 
and  the  axioms  of  F.  Assertions  describing  states  are  denoted  by  l,P,...,G,G’,...  These 
assertions  (but  not  the  assertions  in  rule  definitions)  are  restricted  to  be  conjunctions 
of  atomic  assertions.  We  write  R<l  to  denote  that  R  is  a  conjunct  in  I.  L(F)  denotes  the 
logic  of  F,i.e.  the  set  of  consequences  of  the  rules  of  F.  Substitutions  oc  do  not 
replace  any  variable  that  occurs  in  the  initial  state  I.  Expressions,  all  of  whose 
variables  occur  in  the  initial  state  are  called  "fully  instantiated". 

STANDARD  FRAME  RULES:  A  set  of  standard  rules  are  assumed  to  be  part  of  every 
frame.  These  are  rules  implemented  in  the  program  construction  methods  of  the 
problem  solving  algorithm; 

RO.  Assignment  Axioms: 

(i)  Simple  Assignment:  P(t){x«-t}P(x) 

(ii)  Conditional  Assignment:  (3Z)P(Z){IF  P(W)  THEN  Y<-W}P(Y) 
i(3Z)P(Z)aQ(Y){IF  P(W)  THEN  Y<-W}Q(Y) 

where  Y-variables  in  P(Y)  do  not  occur  in  P(W),  W-variables  are  special 
variables  occurring  only  in  conditional  assignments,  and  Y<-W  denotes 
the  sequence  of  simple  assignments  between  members  of  Y  and  W  that 
occur  in  the  same  argument  positions  in  P(Y)  and  P(W). 
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Rl.  Rule  of  Consequence:  P=>Q,Q{A}R  P{A}Q,Q=>R 

P{A}R  P{A}R 

R2.  Rule  of  Composition:  P{A}Q,Q{B}R 

P{A;B}R 

R3.  Rule  of  Invariance:  if  P{A}Q  and  I  U  F  =  P  then  l{A}lnv(Q,l) 
where  if  R|,R2,...,Rn  are  the  conjuncts  of  I 
in  the  fixed  order,  then  l0  =  0, 
for  0<m<n,  lm<1  =  lm  a  Rm  if  -<lm  U  F  o  ,Rm) 

L,  -  In,  otherwise, 
and  Inv(Q.I)  =  ln. 

R4.  Change  of  Variables:  P(x){A(x)}Q(x)  where  y  is  not  a 

.  special  variable. 

P(y){A(y)}Q(y) 

R5.  Conditional  Rule:  PaQ{A}R,  Pa-,Q{B}R 

P{IF  Q  THEN  A  ELSE  B}R 

R6.  Undetermined  values:  If  l’{?}G  cannot  be  solved  and 
-,(|’UF  =>  ■'G)  then  G  is  UNDETERMINED  in  I’. 

STANDARD  RULES 


REMARKS:  The  axioms  R0(ii)  define  the  semantics  of  conditional  assignment  statements. 
The  occurrence  of  P(W)  within  the  IF  statement  is  interpreted  as  a  call  to  a  procedure 
with  variable  parameters  W,  the  result  of  which  is  to  bind  those  W-parameters  to 
values  that  make  the  Boolean  statement  P(W)  true,  if  such  values  exist.  We  have 
adopted  a  convention  on  W-variables,  w(,w2,...  whereby  they  occur  only  in  conditional 
assignments  as  above,  and  indicate  the  use  of  an  atomic  assertion  as  a  procedure  call 
(we  call  them  "special  variables").  This  eliminates  the  need  for  explicit  Skolem 
"successor"  functions  for  each  relation  in  the  frame.  Note  that  if  -,(3Z)P(Z)  is  true  of 
the  input,  then  the  rule  "says"  that  the  THEN  part  of  the  IF  statement  is  not  executed 
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Invariance  states  that  things  stay  the  same  unless  it  can  be  proved  that  they  conflict. 
This  is  a  way  of  dealing  with  the  "frame  problem"  [McCarthy  and  Hayes  1969],  but  it 
does  force  the  user  into  being  careful  about  stating  what  does  change.lnvariance  can  be 
derived  within  the  logic  of  programs  from  a  rule  which  states  that  procedures  do  not 
have  side  effects.  Undetermined  values  is  a  rule  for  deciding  when  to  construct 
conditional  statements  (section  2.4).  The  change  of  variables  rule  is  an  instance  of  the 
rule  of  substitution  (see  [Hoare  1969]for  this  and  the  remaining  rules). 
Usually, restrictions  are  placed  on  R4  to  maintain  consistency,  In  this  system  the  use  of 
the  assignment  axioms  RO  is  restricted.  However,  the  user  can  introduce  a  primitive 
assignment  procedure  (see  below)  which  would  not  be  restricted  in  its  use;in  this  case 
he  should  use  a  formulation  which  distinguishes  between  a  variable  and  its  value. 

INPUT  FRAME  RULES:  In  addition  to  the  standard  rules,  a  frame  may  contain  rules  of  the 
following  types  (these  constitute  the  user  defined  elements  of  the  frame): 

51  Primitive  procedures  (or  operators):  the  rule  defining  procedure  p  is  of  the  for" 
Pjp’Q.  The  assertions  P  and  Q  are  the  pre-  and  post-conditions  of  p.  p  must  cont?'  ,  a 
procedure  name  and  parameter  list. 

52  Iterative  rules:  an  iterative  rule  definition  containing  the  Boolean  expressions 
P(basis),  Qdoop  invariant),  R(iteration  step  goal),  L(control  test)  and  G(rule  goal)  is  a 
rule  of  inference  of  the  form: 

(a)  P  ,  I-  Q,  QaL{?}R,  R{??}Qv-L 

P{ while  L  do  ?;??}G 

where  the  free  variables  of  R  and  L  occur  in  Q.  Such  rules  are  permitted  not  to  contain 
P  or  L,in  which  case  they  correspond  to  inferences  of  the  form: 

(b)  Q,' QaiG{?'(R,  R{??!-QvG 


Q{while  ->G  do  ?;?? }G 

53.  Definitions.  A  definition  of  G  in  terms  of  P  is  a  logical  equivalence  |-  P=G. 

54,  Axioms.  A  frame  axiom  P  is  a  logical  axiom  |-  P. 

Terms  and  predicates  in  assertions  may  contain  calls  to  LISP  functions.  If  the  frame 
definition  contains  functional  terms  or  predicate  tests  that  are  evaluated  by  calls  to 
LISP  functions,  the  set  of  premisses  must  be  expanded  to  include  both  the  input-output 
assertions  for  these  function  calls  and  the  logical  axioms  for  the  relevant  data  types. 

REMARKS  (i)  The  iterative  schemes  S2  permit  the  definition  of  methods  for  constructing 
loops;  they  are  instances  of; 
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WEAK  ITERATION  RULE:  QaL{B}Qv-L 


Q{WHILE  L  DO  B}-L 

* 

where  Q  is  the  invariant  of  the  loop.  The  meaning  of  |-Q  in  the  premiss  is  that  the  rule 
may  only  be  applied  in  states  where  Q  is  a  first  order  consequence  of  the  state 
description.  The  program  part  ??  is  restricted  to  be  a  sequence  of  assignment 
statements  (see  Section  6).  (ii)  Inconsistencies  may  arise  in  several  different  ways  in 
frames.  The  axioms  can  be  inconsistent,  or  the  post  conditions  of  a  rule  can  be 
inconsistent  with  the  axioms.  Also  the  dements  of  iterative  schemes  must  satisfy  some 
simple  consistency  criteria  (section  6).  (iii)  Note  that  each  frame  rule  has  a  goal.  The 
goal  of  a  procedure  is  its  postcondition;  the  goal  of  an  axiom  or  definition  is  its 
consequent.  If  invariance  (R3)  is  applied  to  program  part  A  constructed  from  applying  a 
single  frame  rule, then  Q  is  the  goal  of  that  rule. 

The  following  lemma  is  useful  in  proving  properties  of  conditional  assignments 
[igarashi, London, Luckham  1973]: 

OR-LEMMA  P{ A }Q,  R{A}S 


PvR{A}QvS 

EXAMPLE:  Next,  we  show  how  a  rather  simple  problem  can  be  stated  within  our  frame 
formalism.  This  leads  us  very  quickly  into  the  further  questions  of  (i)  defining  simple 
general  methods  of  finding  solutions,  (ii)  formulating  the  correctness  of  solutions,  and 
(iii)  the  correctness  of  solutions  obtained  in  frames  that  have  unintended  or  nonstandard 
interpretations. 

Consider  the  following  frame  and  problem: 

INPUT  FRAME  RULES: 

1.  Procedure:  standon 

AT(x,y)AAT(z,y)AROBOT(x)ABOX(z){standon(x,z)}ON(x,z). 

F2.  Procedure:  step-up 

ROBOT(x)AON(x,y)ASTACKED(z,y){step-up(x,y,z)}ON(x,z). 

F3.  Iterative  Rule:  climb 

ROBOT(M)AON(M,y)ASTACKED(u,y)AONTOP(M){?}ON(M,u) 


ROBOT(M)AON(M,y)ASTACKED(u,y){WHILE-ONTOP(M)DO  BEGIN  ?;??  END}0NT0P(M) 
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F4.  Axiom;  R0B0T(x)A3y(0N(x,y)AYz-STACKED(z,y))«0NT0P(x). 

PROBLEM: 

I:  ROBOT(M)aBOX(B1)aBOX(B2)aBOX(B3)aAT(B1,L)aAT(M,L) 
aSTACKED(B2,B1)  a  STACKED(B3,B2). 

G:  ONTOP(M) 

FROBLEM  1;  CLIMBING 

COMMENTS  ON  PROBLEM  1; 

i.  The  iterative  rule  says  "A  solution  to  the  problem  of  climbing  one  box  at  a  time,  can 
be  used  to  construct  a  WHILE  loop  that  solves  the  problem  of  climbing  a  stack  of 
boxes".  The  rule  defines  the  meaning  of  WHILE  in  the  environment.  Or,  if  we  regard 
WHILE  as  a  primitive  constructor  whose  meaning  we  understand,  the  rule  is  an  induction 
principle  for  the  env  ronment. 

ii.  The  program  part  ??  in  the  conclusion  of  the  iterative  rule  transforms  the  situation 
after  the  execution  of  the  loop  body  (?)  back  into  one  in  which  the  invariant  is  again 
true  if  the  test  'S  true: 

0N(  x,u)  { ??  I-ROBOT  (x)  aON(  x,y)  aST  ACKED(  u,y). 

We  restrict  V  to  be  a  sequence  of  assignments. 

iii  The  goal  of  climb  is  ONTOP(M),  the  negation  of  the  control  test  in  this  example. 

Steps  taken  by  a  search  procedure  in  solving  this  problem  are  shown  in  Figure  2.  It 
starts  with  state  situation  I  and  determines  by  logical  reasoning  from  I  and  the  axioms 
which  operators  have  pre-conditions  that  are  true  in  I  .  It  applies  these  operators  and 
updates  the  state  to  the  new  state  using  the  rule  of  invariance,  it  repeats  this  process 
on  the  new  states.  Node  6  indicates  the  initiation  of  a  subproblem  (the  premiss  of  the 
iterative  rule)  with  a  new  initial  state  (the  invariant)  which  is  a  subset  of  the  state 
above  it  at  Node  5. 
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SEARCH  FOR  SOLUTIONS  TO  THE  CLIMBING  PROBLEM 
Figure  2 


The  solutions  corresponding  to  the  paths  shown  in  figure  2  are: 

(i)  l{ st andon( M,B  1  );st epupt M,B  1  ,B2);st epup{ M,B 2,B3) }ONTOP( M). 

(ii)  l{standon(M,B  1  );y--Bl ;u^-B2; 

WHILE  ONTOP(M)  DO  BEGIN 
stepup(M,y,u); 
y'-uj 

IF  STACKED(w,y)THEN  u«-wj 
END)ONTOP(M) 

where  the  assignments  within  the  WHILE  loop  correspond  to  the  ??  of  the  iterative  rule. 
The  variable  w  is  a  special  variable. 

NOTE:  It  looks  as  though  solution  (ii)  is  more  general  than  solution  (i). 

Using  the  frame  rules  we  can  now  construct  a  proof  of  the  statement  l{solution}G  within 
the  logic  of  programs. 
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1 .  |3(ROBOT(M)aAT(M,L)aAT(B  1  ,L)aBOX(B1  )) 

2.  I{st andor.(M,B  i ) }ON(M,B  1 ) aSTACKED(B2,B  1 ) aROBOT(M)  1  ,F  1  ,R4,R  1  ,R3 

3.  ON(M,B1)aSTACKED{B2,B1)aROBC  f(M){y<-B  1 ; 

j<-B2 }R080T ( M) aON( M,y) aST ACKED( u,y)  RO(i),R2,R3 

4.  l{standon(M,Blhy«-Bl;u<-B2}ROBOT(M)AON(M,y)A$TACKED(u,y)  2,3,R2 

5.  ROBOT(M)AON(M,y)ASTACKED(u,y){stepup(M,y,u)}ON(M,u)AROBOT(M)  F2,R4 

6.  ROBOT ( M) aON( M,u)  {y<-u }ROOOT ( M) AON(M,y)  R0,R3 

7.  0N(M,y)A3zSTACKED(z,y){IF  STACKED(w,y)TH£N  u«-w}ON(M,y)ASTACKED(u,y)  R0,R3 

8.  *'3zSTACKED(z,y)A0NT0P(M){IF  STACKED(w,y)THEN  u<-w}ONTOF’(M)  RO 

9.  (0N(M,y)A3zSTACKED(z,y))v(-3zSTACKED(z,y)A0NT0P(M)) 

{IF  STACKED(w,y)THEN  u-w}(ON(M,y)ASTACKED(u,y))v  ONTOP(M)  OR-Lemma  7,8. 

10.  R0B0T(M)A0N(M,y)A^(3z)STACKED(z,y)  o  ONTOP(M)  F4, 

^(0N(M,y)A3zSTACKED(z,y))v0NT0P(M) 

ROBOT(M) aON( M,y) a  3zSTACKED(z,y)  =>  <0N(M,y)A3zSTACKED(z,y))v0NT0P(M) 
ROBOT(M)AON(M,y)  ^  (0N(M,y)A3zSTACKED(z,y))v0NT0P(IV) 

1 1.  ROBOT(M)AON(MIy)ASTACKED(uly){stepup(M,y,u);y>u; 

IF  STACKED(w,y)THEN  u*-w}(ON(M,y)ASTACKED(u,y»v  ONTOP(M)  5,6,10,9,R2,R1 

12.  ROBOT(M)AON(M,y)ASTACKED(u,y){WHILE^ONTOP(M)  DO  ...}ONTOP{M)  11.R1.F3 

13.  I{ solut ion  (ii)}ONTOP(M)  4,1 2, R2 

PROOF  of  l{solution  (ii)}G 

We  refer  to  a  formal  proof  of  L(F)||-I{A}G  as  a  correctness  proof.  The  existence  of 
such  a  proof  implies  only  that  the  program  is  correct  relative  to  the  frame.  Thus  it  is 
easily  seen  that  the  final  state  implies  ( Vx)(BOX<x)=>ON(M,x)),  hardly  a  situation  we  had 
intended,  but  which  arises  from  the  invariance  rule  owing  to  our  not  having  axioms  such 

3S 

ON(M,x)AON(M,y)=>x=y. 

In  other  words,  our  frame  admits  non-standard  models 

We  could  extend  the  frame  by  adding  this  additional  logical  axiom  and  go  back  to 
solving  the  problem  all  over  again.  But  this  would  have  to  be  repeated  if  some  other 
non-standard  model  was  discovered  still  later.  We  ought  to  be  able  to  do  better  than 
that! 

Now,  solution  (ii)  may  still  be  "correct"  (or  solve  the  problem)  in  the  extended  frame. 
And  we  can  determine  this  from  the  proof  of  l{solution  (ii)}ONTOP(M)  by  checking  to 
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see  if  any  step  uses  facts  from  an  intermediate  state  situation  I’  that  contradict  the 
extra  logical  rule,  In  other  words,  we  can  "run"  the  proof  on  the  new  world  with  a 
special  consistency  check  against  the  additional  facts.  This  ought  to  be  much  easier 
than  solving  the  problem  again  from  scratch. 

The  proof  above  formalizes  (i.e.  provides  a  description  for  the  purposes  of  analysis) 
WHAT  it  is  the  problem  solver  has  finally  done  when  it  has  solved  the  problem.  It  is  a 
record  of  those  features  of  the  frame  and  initial  state  that  were  essential  in 
constructing  the  solution.  For  example,  we  have  actually  proved 
ROBOT(M)ABOX(Bl)A$TACKED(B2,Bl)AAT(M,L)AAT(Bl,L)<;Solution(ii)}ONTOP(M) 
within  L(F).  This  proof  did  not  use  BOX(B2),BOX(B3),or  STACKED(B3,B2l  If  there  was 
a  stacking  operator  in  the  environment,  we  could  alter  the  proof— without  having  to 
resort  to  the  problem  solver  again  —  to  eliminate  the  hypothesis  "Stacked  (B2,B1)".  It 
will  be  noticed  that  a  similar  proof  for  solution  (i)  use*  more  properties  of  I;  solution  (i) 
IS  less  general. 

It  is  therefore  plausible  that  a  correctness  proof  for  a  solution  program  will  be  useful  in 
answering  further  questions  about  that  program  such  as:  Does  it  solve  this  new 
problem?  Can  it  be  altered  to  solve  a  given  ne-v  problem?  Are  there  problems  it  will 
work  on  that  another  program  won’t? 


PROBLEM  1 :  T HAND -OR -AND  TREE  SEARCH 
Figure  3 
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2.3  THE  FORMAL  PROBLEM  SOLVING  ALGORITHM 

To  automate  solving  simple  problems  of  this  kind  it  is  sufficient  to  use  a  straightforward 
problem  reduction  search  [Nilsson]  Figure  3  illustrates  the  depth  first  reduction  of 
goals  to  subgoals  using  the  input  frame  rules  (as  described  below)  until  subgoals  are 
reached  that  are  true  in  the  current  state.  In  figure  3,  there  are  two  kinds  of  nodes, 
Goal  nodes  and  Rule  nodes  corresponding  to  the  separate  steps  of  (1)  choosing  a  rule 
to  use,  and  (2)  generating  the  subgoals  necessary  to  apply  that  rule  Goal  nodes  may 
be  any  combination  of  THAND, (defined  below)  OR,  AND,  but  Rule  nodes  are  always  OR 
nodes  [Nilsson  1971],  The  arrows  from  each  rule  node  Doint  to  its  immediate  subgoals. 

If  a  node  reduces  to  an  OR  of  its  subgoals  (which  a'-e  thus  OR-  nodes),  it  has  no  angle 
mark;  i'  it  reduces  to  a  THAND  of  its  subgoals  the  relevant  arrows  are  connected  by 
one  argle  mark;  an  AND  of  subgoals  is  denoted  by  two  angle  marks,  Each  rule  node  is 
labelled  <n,Fm>  where  n  is  the  order  in  which  it  was  achieved  (  omitted  if  it  was  not) 
and  Fm  is  the  frame  rule  used;  similarly  goal  nodes  are  labelled  <n,Gm>. 

We  give  an  informal  description  of  the  reduction  algorithm  (or  subgoaler)  in  the  simple 
case  where  it  does  not  contain  the  rule  of  undetermined  values,  as  follows: 

The  subgoaler  computes  on  a  triple,  <G’,I’,A>,  where  G’  is  the  subgoal  to  be  attempted 
next,  I’  is  the  description  of  the  current  state,  and  A  is  the  current  partial  answer.  Let 
^  be  a  sub  tution  that  replaces  variables  by  terms  from  I  (the  Initial  state).  Nodes  in 
the  subgoal  tree  are  developed  by  using  input  rules  in  F:  if  a  rule  of  F  has  a  conclusion 
or  postcondition  Q  such  that  Q*  =  G’  then  the  rule  is  USED  to  develop  the  node  by 
appending  its  premisses  or  preconditions  as  subgoals  of  G’.  Q  is  said  to 

match  G". 

A  goal  G"  is  ACHIEVED  in  one  of  four  ways: 

(a)  if  there  is  an  c<  such  that  I’  U  F  ^  G’«x, 

(b)  if  not  (a),  then  G’  is  developed  using  an  instance  of  a  frame  rule  with  post-condition 
(or  goal)  Qoc.  Let  the  immediate  subgoals  of  G’  be  G1*G2  where  *  is  the  principle 
connective  in  the  preconditions  of  the  frame  rule,  so  that  G1  and  G2  are  *-nodes.  In 
this  case,  G’  is  ACHIEVED  if: 

(i)  one  of  G1  or  G2  is  achieved  (in  the  case  *  is  OR), 

(ii)  both  G1  and  G2  are  achieved  (in  the  case  *  is  THAND), 

(iii)  both  G1  and  G2  are  achieved  (in  that  order,  say)  and  the  updated  state 
(defined  below)  that  results  from  achieving  G2  also  satisfies  G1  (in  the 
case  *  is  AND). 
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If  G’  is  achieved  under  (a)  there  is  no  change  in  the  current  state  and  answer. 
However,  in  case  <b),  both  are  UPDATED  as  follows:  let  I’  be  the  current  state  ;esulting 
from  achieving  G1*G2;  the  state  resulting  from  achieving  G’  is  lnv(Q<*,l’).  A  is  composed 
(by  R2)  with  the  procedure  call  or  while  statement  corresponding  to  the  rule  that  was 
used  to  develop  G*. 

A  node  in  the  THAND-OR-AND  tree  FAILS  when  the  goal  associated  with  the  node 
cannot  be  achieved  -  essentially  because  it  is  not  true  of  the  associated  state  and 
either  no  rule  can  be  applied  to  reduce  it  or  one  of  its  subgoals  is  not  achievable. 
Whenever  a  goal  node  fails,  the  search  procedure  (simplest  form)  "BACKS  UP"  to  the 
goal  node  immediately  PRECEDING  it  and  attempts  the  next  OR-possibility  for  that  goal. 
The  search  is  DEPTH  FIRST. 

Thus,  an  AND  assertion  is  achieved  when  all  of  its  elements  (subgoals)  have  been 
achieved  simultaneously  in  the  same  state;  a  THAND  assertion  requires  only  that  its 
subgoals  be  achieved  in  some  order  but  not  necessarily  simultaneously. 

This  simple  kind  of  search  algorithm  can  be  implemented  quite  easily  using  the  goal  tree 
generation,  automatic  backtrack  and  data  base  access  functions  of  MICRO  PLANNER 
[Hewitt  1971,  Sussman  and  Winograd  1972],  or  any  of  the  other  current  problem 
solving  languages.  However.it  is  necessary  to  distinguish  behveen  the  formal  algorithm 
and  the  implementation  since  the  latter  can  only  approximate  some  of  the  formal  rules. 

THE  UPDATE  PROBLEM  The  updating  of  a  state  to  the  new  state  resulting  from  the 
application  of  an  input  rule  is  formulated  by  invariance.  In  general  the  rule  of 
invariance  is  not  computable,  but  even  in  cases  where  it  might  be,  it  is  IMPRACTICAL. 
The  implementation  or  this  rule  has  to  fall  short  of  its  formulation.  Inconsistencies  in 
the  state  description  are  almost  certain  to  arise  eventually.  We  can  try  to  delay  this 
by  paying  special  attention  to  those  axioms  that  are  most  likely  to  be  transgressed  (e.g. 
uniqueness  and  single-valuedness  properties).  The  case  of  ITERATIVE  rules  provides  a 
particular  difficulty  since  the  rule  goal  G  may  not  provide  enough  information  about 
what  went  on  during  the  iterations  of  the  loop  body  to  continue  planning  after  an 
application  of  such  a  rule.  We  allow  the  user  to  specify  an  output  assertion  as  part  of 
an  iterative  rule,  in  which  case  invariance  is  applied  using  this  assertion  in  place  of  the 
usual  rule  goal  (see  section  6). 


2.4  CONDITIONALS. 

Extending  the  description  of  the  goal  reduction  algorithm  to  include  the  rule  of 
undetermined  truth  values  follows  closely  the  actual  system  implementation  discussed  in 
Section  5.  Here  we  give  some  motivation  for  rules  R5  and  R6. 

Conditional  statements  ere  constructed  whenever  an  undetermined  goal  occurs.  The 
notion  of  undetermined  truth  value  used  here  is  an  operational  one.  The  problem 
solver  wants  G’  to  be  true  in  I’,  G’  is  not  true  in  I’,  no  way  of  making  G’  true  can  be 
found,  and  G’  is  not  false  in  I’.  In  such  cases,  the  algorithm  continues  by  splitting  its 
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problem  into  two  subproblems:  to  solve  a  more  global  problem  G*  say,  (a)  assuming  G’ 
is  true  and  (b)  assuming  G’  is  false. 

For  example,  relative  to  the  frame  in  problem  1  we  can  pose  a  second  problem, 

1 1  >?}ONTOP(M)  where  II  differs  from  I  only  in  not  containing  the  assertion  AT(M,L)  Our 
solution  (ii)  above  is  no  longer  a  solution  to  this  new  problem  since  AT(M,L)  is  not  true 
in  II  (neither  is  it  known  to  be  false!)  and  there  is  no  way  of  achieving  it,  Using  R6  and 
R5  ,t he  extended  algorithm  can  construct  the  solution: 

(iii)  1 1  {IF->A1  M,L)  THEN  CALL  PROCl(M.L)  ELSE 
BEG.Ij 

standon(M,B  1  );y*-B  1  ;u*-B2; 

WHILEONTOP(M)  DO 

BEGIN  stepup(M,y,u);  y<-u; 

IF  STACKED(w.y)  THEN  u<-w; 

END 

END)ONTOP(M) 

and  the  proof  of  correctness  of  solution  (ii)  can  be  extended  to  a  proof  of  II {solution 
(iii)}ONTOP(M). 

The  implementation  of  these  rules  is  complicated  by  considerations  such  as  the 
following. 

(a)  A  stack  is  required  for  the  subproblems  for  cases  when  undetermined  subgoals  are 
assumed  false,  i.e.  subproblems  for  the  form  I,a-’G’{PROCN}G*. 

(b)  •  Criteria  for  the  choice  of  G*  are  required.  For  example,  the  contingency  problem 
above  is  II  a-AT(M,L){PROC1(M,L)  }ONTOP(M).  Although  the  problem  solver  has  found 
that  it  cannot  solve  1 1  {? } AT(M,L),  there  is  no  reason  to  suppose  that  this  is  a  good 
choice,  or  indeed  that  it  can  be  solved.  We  might  have  chosen 
1 1  a-AT(M,L){PROC  1  JON(M,B  1 )  instead. 

(c)  The  order  in  which  goals  are  attempted  may  affect  not  only  whether  a  solution  can 
be  found,  but  also  whether  the  solution  is  sensible. 

(d)  Undetermined  truth  values  can  also  arise  as  a  result  of  applying  unreliable 
operators,  for  example: 

AT( hand, x)aAT( object, x){|i ft(hand, object) }HAS(hand, object) v  DROPPED(hand, object). 

We  shall  consider  these  problems  in  detail  in  Section  5, 


2.5,  CORRECTNESS  OF  SOLUTIONS 

In  the  previous  examples  we  showed  that  if  the  frame  rules  were  taken  as  assumptions 
then  the  solutions  could  be  proved  within  the  logic  of  programs  to  solve  the  problems. 
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This  is  what  we  mean  by  the  CORRECTNESS  of  the  solutions.  The  proofs  require  the 
standard  rules,  but  these  are  all  rules  of  the  logic  of  programs,  wi  h  the  exception  of 
invariance  and  undetermined  values.  A  proof  of  correctness  of  a  solution  generated  by 
the  formal  problem  solving  algorithm,  based  on  the  frame  in  which  the  problem  was 
Lf  -Iran  he  -iven  ir.  every  case.  This  does  not  guarantee  the  correctness  of  every 
actual  To! ution6'since,  as  we  have  seen,  the  implementation  only  approximates  certain 
rules  of  the  formal  algorithm.  It  is  a  justification  of  the  formal  methods.  In  addition  it 
nrovides  a  measure  of  confidence  in  actual  solutions  relative  to  the  soundness  of  the 
frame  (Which  is  the  user’s  responsibility)  and  to  the  degree  to  which  unsound  heuristics 
i^,  imclttffioafcation  have  been  invoked  in  finding  a  solution.  In  fact,  the  result  allows 
us 'to  state  sufficient  conditions  under  which  actual  solutions  will  be  correct,  but  we  win 

not  do  that  here. 

To  establish  this  result  it  is  necessary  to  prove  (a)  a  successful  search  t'ee  of  the 
formal  algorithm  has  certain  properties,  and  (b)  a  tree  with  tnose  propeities  can  be 
transformed  into  a  correctness  proof  of  the  solution.  We  shall  state  without  proof  the 
properties  of  successful  searches,  and  then  give  the  details  of  step  (b). 

Let  us  first  consider  the  very  restricted  case  where  (a)  no  calls  to  LISP  functions  take 
place  (b)  no  undetermined  goals  occur,  and  (c)  no  iteration  rules  are  used.  We  assume 
that  the  problem  is  stated  in  the  form  !{?}G  where  G  contains  only  variables  occurring  in 

I. 

Tho  cuhpoalinp  algorithm  treats  v  (or)  as  exclusive;  in  order  to  achieve  P(x)  v  Q(x)  it 
Wes  to  achieve  P(x)  and  if  this  fails  it  tries  Q(x),  When  the  subgoaler  completes  a 
successful  computation  it  has  constructed  a  goal  tree,  Tr  say,  and  a  substuuHon  c*.  Tr 
consists  solely  of  goal  nodes  (the  single  rule  node  between  a  goal  and  its  subgoals  in 
fhe  completed  search  tree  can  be  eliminated  and  the  arrows  leading  directly  from  the 
goal  to  its  subgoals  labelled  by  the  rule  name).  Tr  and  *  have  the  following  properties: 

(1)  each  node  of  Tr  has  associated  with  it  the  number  n  if  it  was  the  nth  node  to  be 
achieved,  a  Boolean  expression  G(n)  (its  goal),  a  program  pari  A(n),  and  a  s  a 
condition  l(n), 


(2)  •:<  substitutes  terms  from  I  for  variables  in  Tr, 


(3)  IUF|-G(  1  )d, 

(4)  if  G(n+1)  is  at  a  leaf  node  then  l(n)UF|-G(n+l)c<:, 

if  G(n+i)  is  not  at  a  leaf  node  then  it  is  related  to  its  immediate  subbgoals 
G(k>  GW  by  a  procedure  P'pjQ  or  a  definition  P»Q  such  that  CV-G<n+lWA<y«  and 
P  v  G(k)t...tG(n), where  *  is  either  AND  or  THAND.  G(n+l)is  achieved  from  Kn). 

/ gun  cases  3  and  4, and  where  a  definition  was  used  to  develop  G(n+1),  l(n+lH(n)  and 
»/  +iv_ A(n)’  in  the  case  of  a  procedure  call  of  the  form  Po^pc-^Qcv.,  I(n+1)  is 
lnv(Q.v ,|(n))  and  A(n+l)=A(n);p.v.  Finally,  the  property  that  G(n+1)  is  achieved  from  l(n) 
implies  that  l(n)UF|-P*.  (NOTE:  this  use  of  "|-  is  an  extension  of  the  usual  notion  of 


I 


IS 
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first  order  proof  in  the  case  when  Per:  is  a  THAND;  however  it  is  easily  seen  that 
THAND  connectives  may  be  eliminated  from  frames  by  introducing  extra  definitions,  so 
the  extension  is  not  essential ) 

Let  the  root  of  Tr  be  Ihe  mTH  node.  We  may  prove  that  the  output  program  A(m) 
solves  the  problem,  i.e.,  L(F)  ||-  l{ A(m)}G,  (here  G(m)=G)  by  proving  a  similar  result  for 
each  intermediate  goal  and  partial  answer.  Namely,  for  each  n<m,  L(F)  ||-l{A(n)}l(n)  and 
l(n)^G(n)cv  can  be  proved  by  induction  on  n.  The  cases  are  as  follows. 

First,  L(F)||-  I  ^  G<  1  ):*i  by  property  (3)  above. 

Now  assume  L('  )  ||-  l{ A< n) }l( n). 

If  G(n+1)  is  at  a  leaf  node  then  l(n)UF^G(n+l)«:,  l(n+l)=l(n),  and  A(n+l)=A(n).  Thus 
L(F)||-  l{A(n+l)}l(n+l)  and  L(F)  ||-l{A(n+l)}G(n+l)<x  by  the  rule  of  consequence  Rl. 

If  G(n+1)  is  riot  a  leaf  node  then  l(n)UF|-Pcv  by  property  (5)  above,  If  G(n+1)  is  related 
to  its  immediate  subgoals  by  a  procedure,  say  P{p}Q,  then  P<x{p}Qo^  is  derivable  by  the 
change  of  variables  rule  R4.  The  rule  of  consequence  implies  L(F)  ||-  l(n){ p<*:}Q<*  and 
invariance  implies  L(F)||-  l(n){p^}l(n+l).  Rule  R2  allows  the  composition  of  this  with  the 
inductive  assumption  so  that  L(F)  |j-  l{A(n);p<x}l(n+l).  Finally  l(n+l)  |-  G(n+1)<*  since 
Qy=  G(n+1)<*  a  QVa  Tiie  case  when  G(n+1)  is  related  to  its  subgoals  by  a  frame 
definition  is  straightforward. 

Thus,  by  induction  on  n  we  can  prove  L(F)  ||-  l{A(m)}l(m)  and  l(m)=>G«:.  Finally  we  note 
that  if  G  contains  only  variables  occurring  in  I  then  G<*=G.  Therefore,  we  have  proved 
L(F)  ||-  l{A}G. 

The  extension  of  this  proof  for  the  case  when  there  are  undetermined  goals  is  given  in 
Section  5,  and  for  the  case  when  iterative  rules  are  used  in  Section  6. 


20 


3.  DEFINING  THE  PROGRAMMING  ENVIRONMENT 

In  this  section  the  Frame  definition  formalism  is  presented  This  includes  the  Frame 
language  the  Advice  language,  and  the  output  Program  language.  A  complete  example 
of  an  input  frame,  together  with  advice,  and  the  resulting  output  program  is  given. 

3.1  FRAME  LANGUAGE 

3  1.1  ASSERTIONS:  The  syntax  for  assertions  used  in  definitions  of  rules,  axioms  and 
state  descriptions  is  shown  in  Figure  4. 

<variable>  ::=  <identifier> 

<function  symbol>  ::=  <identifier> 

<predicate  symbol  :  •  <identifier> 

<term>  <variable>|(<function  symbol>)| 

(function  symbol><argument  list>) 

<argument  list>  ::=  <term>|<term>, Argument  list> 

<functional  term>  (EV<term>)|(EVN<term>)|<tsrm> 

<atomic  formula>  <predicate  symbol>(<predicate  argument  list>) 

< predicate  argument  list>  ::=  <functional  term>|<functional  term>, 

predicate  argument  list> 

<literal>  ::=  <atomic  formula>|-’<atomic  formula> 

<literal  element>  <literal>|REQUEST(<literal>)|{<assertion>} 

<disjunction>  <literal  e!ement>|<literal  element><or><disjunction> 

<assertion>  ::=  <disjunction>|<disjunction><and><assertion> 

<and>  ::=  a|& 

<or>  v|® 

SYNTAX  OF  ASSERTIONS 
Figure  4. 

Identifiers  are  strings  of  characters  not  containing  the  negation  symbol,  nor  the 
usual  LISP  delimiters,  e.g.,  blanks,  commas  or  parentheses.  The  <or>  connectives  have 
higher  precedence  than  the  <and>  connectives  and  a  logical  condition  is  terminated  by  a 

semicolon, 

The  only  constructs  whose  meaning  requires  special  explanation  are  functional  term>, 
<literal  element>,  and  the  connectives  and  "b". 

If  a  term  is  in  the  scope  of  the  modifier  "E V"  then  all  functions  in  that  term  are  applied 
to  their  arguments  (i.e.  evaluated  as  LISP  functions)  when  that  literal  is  used  in  the 
problem-solving  process.  "EVN"  further  specifies  that  the  functions  to  be  evaluated 
have  numerical  values.  The  default  convention  is  that  the  term  is  manipulated  as  an 
unevaluated  symbolic  expression.  The  "REQUEST"  modifier,  which  takes  a  literal  as  its 
argument,  alters  the  way  that  literal  is  treated  by  the  problem  solver.  This  is  discussed 

in  Section  4, 

The  AND  connective  is  denoted  by  "a"  .  Thus  a  state  satisfies  the  assertion  AaB  if  it 
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satisfies  both  A  and  B.  The  weaker  THANO  connective  Is  denoted  by  &  (Section  2). 
Exclusive  OR  is  denoted  by 

3  1  2  STATE  DESCRIPTIONS:  Assertions  specifying  states  are  restricted  to  be 
conjunctions  of  literals. 

*  1  3  AXIOMS-  Axioms  are  stated  in  either  of  the  forms  P=Q  or  P,  where  P  and  Q  are 
assertions^  They  hold  in  all  states  and  are  used  to  complete  a  giver,  state  description 
by  deduction  of  other  elements  of  a  state  from  those  given. 

3.1.4  RULES:  There  are  three  types  of  rules:  primitive  procedures,  definitions,  and 
iterative  rules. 

(a)  A  primitive  procedure  Is  specified  by  a  name,  an  argument  list,  and  its  pre  and  post 
-  conditions,  i.e. 

P  {f  (x,  ,...,xk  )}Q  where  P  and  Q  are  assertions  in  which  X|  ,...,xK  are  free,  and  f 
is  the  procedure  name. 

The  variables  are  formal  parameters  of  the  procedure.  They  may  be  "bound"  by 
substitution  of  actual  parameters  when  the  procedure  is  applied  to  a  state. 

When  a  orimitive  procedure  is  defined  it  may  be  declared  to  be  an  ASSUMPTION.  If  it 
Uusod  in  a  successful  program  construction,  then  the  user  is  informed  and  is  given .the 
opportunity  to^carry  out  *a  structured  program  development  of  this  non-primitive 
operation.  This  is  described  in  Section  7. 

'b)  A  definitional  rule  Is  of  the  form  R=$  where  R  and  S  are  assertions.  Th®  r®lat|°7’ 

Is  dven  as  the  post-  condition  of  the  rule.  The  meaning  of  a  definition  is  that 
®  •  HAcirpH  that  ^  be  true  it  is  equivalent  to  establish  the  truth  of  R.  A 

definition  is  often  used  to  shorten  assertions  in  rules  by  defining  a  single  relation  as 
equivalent  to  an  often  used  condition. 

t rv  iterative  rules  specify  conditions  that  if  satisfied  justify  the  assembly  of  a  "while" 
t:!,p  to  achieve  theP  associated  goal.  They  are  instances  of  the  iterative  rule  S2  ,n 

Section  2.2,  and  are  defined  by  giving: 

(i)  A  name,  e.g.  TLOOP,  (without  parameters). 

(jjj)  A  lo^p8  i  n  van  ant  "a  s  se  rt  i  on  Q  that  specifies  relations  that  must  be  true  in  the 

(iv)  A  n  ^i  t  e  r  ah  on  'step*  a  s  serf  n°R  that  specifies  the  goals  to  be  achieved  during 

(v)  An  Iterative  goaf*  G,  the  assertion  considered  achievable  by  the  iterative 

vvi\  The^  format  of  iterative  rules  also  allows  the  specification  of  a  loop  control 
test  L  and  an  output  assertion  S  If  they  differ  from  G. 
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The  rule, 

TLOOP 

P;Q;R;G;L;S; 

where  P,Q,R,G,L  and  S  are  assertions, 
defines  the  iterative  rule  "TLOOP" 
associated  with  the  goal  G. 


3.1.5  SPECIAL  AXIOMS:  After  the  rules  and  initial  state  have  been  defined  the  system 
requests  the  following  information  for  each  predicate  symbol  P  that  has  been 
mentioned.  The  system  use  of  this  information  is  discussed  in  Section  4. 

a)  "Is  P  a  function  of  the  state7"  The  intent  of  this  classification  is  to  separate 
those  relations  whose  truth  value  may  be  affected  by  a  state  transformation," 
i.e.,  FLUENT  relations, from  those  whose  truth  value  is  constant  over  all 
achievable  worlds,  i.e.,  NON-FLUENT  relations  such  as  ROBOT(X)  , 
"INTEGER(Y)". 

b)  "Is  knowledge  represented  using  P  partial?"  A  partial  relation  may  have  truth 
values  TRUE,  FALSE,  or  UNDETERMINED.  Partial  relations  may  be  used  to 
represent  incomplete  knowledge  of  the  world  which  may  cause  conditional 
statements  to  be  generated  as  explained  in  Section  5.  A  relation  may  be 
declared  "uncertain"  which  implies  an  absence  of  knowledge  about  it  so  tha*  it 
is  assigned  a  truth  value  of  undetermined  a  priori.  If  P  is  not  "partial"  it  is 
"total"  and  can  only  have  truth  values  of  either  true  or  false.  Thus  rule  R6 
applies  to  partial  predicates  only. 

c)  "Does  P  have  a  uniqueness  property  in  certain  argument  positions?"  A  "yes" 
answer  indicates  that  P  cannot  be  true  for  two  sequences  of  argument  values 
that  differ  only  at  one  of  those  positions  that  are  unique.  The  unique 
positions  are  given  using  the  notation,  (Xl,*,X3,*,...,Xn),  for  example,  to 
designate  the  second  and  fourth  argument  positions.  For  each  unique 
argument  position  in  relation  P(al,...,an),  an  axiom  is  "built-in"  from  which  a 
contradiction  may  be  established  with  P(bl,...,bn)  that  differs  in  a  unique 
position  and  matches  elsewhere. 

For  example  the  statement,  "an  object  can  only  be  in  one  place  at  one  time",  is 
expressed  by,  AT<X1,*).  If  we  add,  "and  only  one  object  can  be  at  any  place",  then  we 
use  AT(*,*)’ 

3.1.6  SIMPLIFICATION:  Algebraic  simplification  rules  may  be  given  to  simplify  the  terms 
that  may  occur  in  subgoals  during  the  problem  solving  phase.  The  simplification  is  driven 
by  a  table  of  rules  of  the  form  s=t  where  s  and  t  are  terms,  occurrences  of  Sec  are 
replaced  by  to£  for  any  substitution  <x. 

The  output  format  of  any  functional  term  may  be  specified  by  the  user  by  giving  a  rule 
in  which  its  input  prefix  form  is  on  the  left,  e.g.,  (PLUS  X  Y)  =  (X+Y). 
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3.2.  ADVICE  LANGUAGE 


The  advice  facility  is  intended  to  enable  the  user  to  impose  structure  relevant  to 
solving  a  particular  problem  upon  an  already  defined  frame.  This  additional  structure 
includes  preference  orderings  among  goals  and  rules,  and  restrictions  on  the  search 
space.  The  preferences  may  also  reflect  the  kind  of  solution  the  user  wants. 


Advice  is  given  during  program  generation  by  means  of  an  interactive  facility.  The 
advice  subsystem  may  be  entered  by  responding  to  a  system  query,  DO  YOU  HAVE 
ADVICE?"  or  by  typing  any  key  during  program  generation.  The  user  may  request  to 
see  the  current  path  in  the  subgoal  tree  i.e.  rules  entered  and  goals  pending,  and 
receive  a  diagnosis  of  the  cause  of  any  failure.  This  is  useful  In  deciding  what  advice 

to  give. 


The  advice  system  enters  a  read  loop  recognizing  and  numbering  commands  from  the 
language  shown  in  Figure  5.  In  the  language  syntax,  optional  symbols  are  enclosed  in 
’T"  and  "l"-  enclosing  a  list  of  symbols  in  and  indicates  that  one  must  be  chosen; 
<rule>  Is  a  rule  name;  <rule  llst>  is  a  list  of  rule  names;  <proc>  Is  a  primitive  procedure 
name;  <advice  num>  is  of  the  form  "  n",  where  n  is  an  Integer;  and  Q  denotes  the  pre¬ 
condition  of  <rule>. 


After  advice  has  been  given  the  system  may  be  directed  to  reject  the  rule  it  is 
currently  using,  if  any,  or  to  try  (perhaps  re-try)  the  current  rule. 

The  advice  facility  is  an  important  tool  for  experimenting  interactively  with  different 
frames  to  determine  their  adequacy  and  soundness.  At  present,  the  language  is 
rudimentary  and  should  be  extended. 

3.3  PROGRAMMING  LANGUAGE 

The  generated  programs  are  expressed  in  an  elementary  ALGOL-like  language  which 
includes  block  structure,  assignment  statements,  conditional  statements,  while  loops,  and 
non-recursive  procedures  calls.  The  procedures  may  be  typed,  including  Boolean,  and 
may  have  side  effects  in  addition  to  the  value  returned.  The  procedure  parameters  are 
normally  called  by  value  except  in  the  case  of  special  W-variables  in  conditional 
assignments  (rule  RO,  Section  2). 
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ADVICE  LANGUAGE 


COMMAND  SYNTAX 

ACTION  PERFORMED 

TRY  <rulel>  BEFORE  <rule2> 

Use  <rulel>  before  <rulc  ’>  to 
develop  a  subgoal . 

FOR  <rule>  [FIRST]  TRY  <literal> 

Change  the  precondition  Q  of  •  rule“> 
to  <literal>  &  Q  if  "FIRST"  is 
given  otherwise  Q  V  <l.iteraL>. 

DELETE  [<rule>,<literal>, 

<advice  num>] 

If  <'rulc>  is  given,  remove  that 
rule.  If  <literal>  then  alter 
state  to  make  <literal>  not  true. 

If  <advice  num>  then  delete  the 
associated  advice  and  undo  its 
effects  on  the  system. 

ADD{  <rule>,<litera  !>} 

If  <rule>  is  given  then  accept  a 
new  rule.  If  <litcral>  then  alter 
state  to  make  <literal>  true. 

ALTER  <rule> 

<rule>  may  be  modified. 

ASSUME  [<rule>,<litera 1>} 

If  <rule>  is  given  then  an  assumed 
rule  may  be  defined. 

If  <literal>  then  alter  state  to 
make  <literal>  true  and  mark  it  as 
an  assumption. 

RESTRICT  <rule>{TO ,FROM] 

<rule  list> 

For  any  goal  in  Q,  if  "TO"  is  given 
then  only  rules  in  <rule  list>  may 
be  used,  if  "FROM"  then  no  rule  in 
Crulc  li st>  will  be  used. 

ADVICE 

All  advice  given  that  session  is 
displayed . 

STATUS 

The  following  information  is  dis- 
p layed : 

-rules  entered  and  goals 
pending  in  currenL  subgoal 
tree  , 

-rules  and  goals  in  longest 
path  obtained  so  far, 

-currently  constructed  program 
segment 

-longest  program  segment 
constructed  so  tar . 

PAIRWISE  INEQUALITIES  <proc> 

Pairwise  equality  is  prohibited 
in  primitive  procedure  argument 
positions  containing  "*  . 

RECURSIVE  <rule> 

The  rule  may  be  used  directly  to 
achieve  a  goal  in  its  pre-condition 
otherwise  it  may  not. 

Figure  5 
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3.4  AN  EXAMPLE 

Consider  the  task  of  writing  a  program  to  compute  the  nth  Fibonacci  number  for  some 
integer  n  This  task  has  been  posed  in  [Balzer  1  972}  The  basic  information  required 
is  the  recursive  definition  and  the  basis  values.  One  way  to  express  this  in  the  Frame 
language  uses  the  following  predicates  with  the  indicated  meanings. 

VFIB(X,Y):  "The  value  of  the  X  Fibonacci  number  is  Y", 

C(X,Y):  "The  contents  of  the  variable  X  is  Y", 

FIB(X,Y):  "The  variable  X  conta'ns  the  Y  Fibonacci  number, 

INTEGER(X):  "X  is  an  integer", 

ISVAR(X):  "X  is  a  variable", 

>(X,Y):  "X  is  greater  than  Y" 

NEWVAR(X.Y):  "X  and  Y  are  local  variables". 

The  problem  is  ISVAR(X3)aINTEGER(N){?}FIB(X3,N). 

The  frame  contains: 

1.  Axioms  VFIB(  1,1  land  VFIB«ADD1  1),2)  (these  define  initial  values). 

2.  Axiom 

TAFIB 

VFIB«SUB1  V1),V2)aVFIB((SUB1(SUB1  V1)),V3)a  =(V4,(PLUS  V 2  V3)); 

VFIB(V1,V4);  . 

(defines  VFIB(V1,V4)  for  term?  beyond  the  initial  values). 

3.  An  iterative  rule  (named  TFIB)  with  goal  FIB(V3,V8);  this  rule  defines  the  conditions 
to  be  satisfied  during  an  iterative  upward  computation.  The  basis  condition  (to  initialize 
the  counter  and  program  variables)  is: 

NE  WVAR(  V 1  ,V2)  aINTEGER(  V8)  aC(  V 1 ,( ADD  1  1  ))aC(  V2, 1 )  aC(  V3,(  ADD  1  1 ));. 

The  loop  invariant  condition  is: 

C  (V  l  ,V5)  aC(  V2,V  9)  aC(  V3,V  1 0)  aVFIB(  V5,V  1  0)aVFIB((SUB1  V5),V9);. 

This  states  that  at  each  entry  to  the  loop  body,  if  the  value  in  the  counter  is  i  and  the 
values  in  the  program  variables  are  j  and  k  then  j  is  the  ith  Fibonacci  number  and  k  is 
the  (i-l)st  Fibonacci  number. 

The  iteration  step  condition 

C(  V 1 ,( ADD  1  V5))  aFIB(V2,V5)  aFIB(  V3,(  ADD  1  V5)); 

specifies  what  the  iteration  step  is  to  accomplish.  The  control  test,  >(V5,V8)  and  an 
output  assertion  FIB(V3,V8)  are  given. 
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4.  A  definition  of  FIB  in  terms  of  VFIB  and  C 
TDFIB 

VFIB(V2,V3)aC(V4,V3);  FIB(V4,V2); 


5.  A  simple  primitive  procedure  for  assignment  is  also  given,  l.e. 
♦-(VI,  Al) 

ISVAR(Vl);  C(Vl,Al)j. 


No  rules  are  declared  as  assumptions.  The  additional  Information  given  to  complete  the 
Frame  specification  Is  shown  in  Figure  6,  and  a  program  generated  from  this  Frame  is 
shown  in  Figure  7. 
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PREDICATE  SYMBOL 


PARTIAL 


UNIQUENESS 


VFIB 

INTEGER 


C(X,') 

EIB(X, *) 

FALSE 

VFIB(*,*, 

FALSE 

FALSE 

FALSE 


SIMPLIFICATION  RULES: 


FUNCTION  OUTPUT  SYNTAX: 


ADD  1  ( SUBI  X))  -  X 
'SUB1  I ADD1  X) )  -»  X 


(ADD1  X)  =  (X+l) 
SUBI  X)  =  Cx-i) 

( PLUS  X  Y)  =  (X+Y) 


ADVICE:  TRY  TFIB  BEFORE  TDFIB 


RECURSIVE  TAF1B 


Figure  6 


hhhhhhht****  ***»♦#*** 


#  •e***  *«-**#*  IHHHt  ** 


PROC1  (XI, N) 

ISVAR( X3) ■ INTEGER(N) ; 
COMMENT 

INPUT  ASSERTION 
NONE 

OUTPUT  ASSERTION 
FIB(XJ.N) 

BEGIN 

yi  -  i+i); 

Y2  -  i; 

xj  -  (1+1); 

WHILE  — 1>( Y 1  ,N)  DO 
BEGIN 

Yi  -  (Yi  +  I); 

zs  -  xj; 

X3  *-  (X3  +  V2); 
Y2  -  Z2 ; 

END 

END 


5*-  wit:  in 


Figure  7 
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During  the  process  of  problem  solving  ard  program  generation,  information  is  needed  at 
many  points  to  reduce  the  cearch  space  or  to  produce  reasonable  programs.  Some  of 
the  information  is  provided  in  the  frame  specification  by  statements  about  the  rules  and 
predicates;  other  useful  facts  are  provided  to  the  problem  solver  in  the  form  of  rather 
simple  advice.  Roughly  speaking,  there  are  six  basic  processes  in  the  problem-solving 
system  where  extra  facts  can  help:  (a)  pattern  matching,  (b)  development  of  nodes  in 
the  subgoal  tree,  (c)  updating  the  state  description  (i.e.  implementing  invariance),  (d) 
backtracking  in  the  subgoal  tree,  (e)  conditional  branching,  (f)  assembly  of  programs. 
Each  fact  (as  opposed  to  a  rule  or  axiom)  in  a  frame  specification  and  each  sort  of 
advice  has  «<t  least  one  function  in  speeding  up  a  basic  process.  Below  we  describe 
some  of  the  ways  in  which  the  present  variety  of  facts  and  advice  Is  used  (full  details 
are  given  in  [Buchanan  1974]). 

(1)  OR-Node  Selection.  When  more  than  one  rule  can  be  applied  to  reduce  a  given 
goal,  some  selection  and  preference  criteria  are  needed.  By  using  the  advice 
system, the  rules  and  axioms  that  may  be  applied  to  achieve  goals  within  the 
precondition  of  a  rule  or  axiom  may  be  restricted  to  or  excluded  from  a  given  list. 
Also,  a  preference  ordering  may  be  specified  among  rules  and  axioms  with  common 
post-conditions.  Goals  within  the  preconditions  of  axioms  are  always  restricted  to 
deduction  within  the  current  state,  i.e.  can  be  reduced  only  by  use  of  other  axioms,  and 
do  not  cause  a  state  transformation  nor  add  any  construct  to  the  generated  program. 

(2)  Predicate  Classification.  A  predicate  P  is  classified  according  to  the  kind  of 
subgoaling  permitted  to  achieve  a  goal  of  the  form  P(t).  If  P  is  declared  to  be  NON¬ 
FLUENT,  then  any  goal  literal  containing  P  can  be  achieved  only  by  deduction  f.rpm  the 
current  state.  No  rules  (procedure,  iterative  or  definitional)  are  applied.  FLUENT  ,goals 
are  attempted  by  deduction  and  state  transformation.  If  a  fluent  predicate  occurs  In  a 
literal  which  is  ihe  argument  of  the  REQUEST  modifier,  then  it  is  treated  as  a  non¬ 
fluent. 

(3)  Goal  Ordering.  The  achievement  of  a  condition  (and  the  efficiency  of  the  output 
program)  is  strongly  influenced  by  the  ordering  of  its  subgoals.  In  particular,  the 
bindings  of  variables  occurring  in  goals  may  be  determined  by  earlier  achieved 
instances.  In  some  cases  only  certain  orderings  will  permit  achievement.  An  objective 
of  an  automatic  problem  solving  system  is  to  determine  the  optimal  subgoal  ^.derlng, 
but  at  present  this  is  provided  by  the  user  when  the  Frame  is  defined  and  may  be 
altered  by  advice,  However,  the  system  automatically  orders  non-flue1"*  goals  first  in  a 
condition;  this  relatively  short  achievement  search  is  used  both  as  a  quick  rejection 
strategy  and  to  get  variable  bindings  of  the  correct  type  for  the  remaining  fluent  goals. 

(4)  Recurring  failures,  When  failure  occurs  in  some  subtree  prior  to  successfully 
solving  a  subproblem,  its  causes  should  be  used  to  avoid  repeating  the  same  failure  In 
the  continued  search  if  possible.  At  present  this  must  be  handled  using  the  interactive 
advice  system.  This  informs  the  user  of  the  current  path  in  the  subgoal  tree,  current 
program  generated,  and  goals  that  fail,  thus  allowing  interactive  correction  when  a 
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ref  tition  occurs.  These  situations  can  also  be  eliminated  by  placing  the  (eventual) 
suLessful  subprograms  on  the  program  library  for  use  as  MACROS. 


(5)  Repetition.  Certain  types  of  looping  behavior  in  the  subgoaler  are  prevented  using 
the  feature  of  the  Frame  language  that  allows  a  rule  to  be  declared  recursive  or  non¬ 
recursive  If  declared  non-recursive,  then  that  rule  will  not  be  used  directly  to  achieve 
a  goal  in  its  pre-  condition  and  it  will  not  be  entered  twice  to  achieve  the  same 
instance  of  its  post-condition  within  the  same  subgoal  tree,  A  more  general  mechanism 
should  consider  not  only  the  current  goal  and  rule  but  also  the  current  state  as  well. 


(6)  Truth  Values.  Though  the  underlying  semantics  is  three  valued,  search  efficiency  is 
gained  by  restricting  relations  involving  certain  predicate  symbols  to  be  two  valued.  If 
a  predicate  P  is  declared  to  be  TOTAL,  then  failure  to  achieve  P  indicates  that  -P  is 
true  Only  true  positive  instances  of  total  predicates  are  stored  in  the  state.  The  rule 
of  undetermined  values  is  not  applicable  to  literals  involving  total  predicates.  The 
additional  processing  required  for  PARTIAL  predicates  is  described  in  Section  5. 


(7)  Useless  Procedure  Calls.  In  some  cases,  the  application  and  generation  of  redundant 
or  trivial  procedure  calls  are  detected  and  avoided.  At  the  moment  this  is  done  by 
placing  restrictions  in  the  frame  on  the  actual  parameters  of  primitive  procedures.  The 
system  will  not  use  an  instance  of  a  primitive  procedure  that  contains  pairwise  equality 
between  its  actual  parameters  that  has  been  prohibited  by  the  user.  For  example,  the 
advice  "PAIRWISE  EQUALITY  MOVEO<l,x2,*,*)"  will  cause  the  rejection  of  the  procedure 
call  "MOVE( MAN, CHAIR, P,P)". 


(8)  Uniqueness  Properties.  Uniqueness  or  single- valuedness  In  argument  positions  of 
certain  predicates  is  sufficiently  important  to  jusiify  a  special  mechanism  rather  than  to 
rely  on  deduction  using  axioms.  The  designation  of  certain  argument  positions  as  unique 
is  equivalent  to  efficiently  building  in  axioms  of  a  particular  form,  e.g.  P(xl,*) 
represents  the  axiom, 

P(xl,x2)  a  x2  ^  x3  -*  -'P(xl,x3). 


These  special  axioms  are  used  for  consistency  checking  (in  the  implementation  of  the 
rule  of  invariance)  when  the  state  is  updated. 


(9)  Context  Linking.  The  context,  which  includes  the  state  and  bindings  on  subgoals 
currently  pending  at  a  node,  should  be  available  to  aid  search  decisions,  e.g. 
instantiations  of  subgoals  or  choice  of  rule,  at  descendent  nodes  in  the  subgoal  tree. 
The  system  has  a  mechanism  that  if  requested  will  keep  track  of  the  instantiated  goals 
at  each  level  of  the  subgoal  tree  so  that  their  variable  bindings  are  available  when 
attempting  iower  level  goals  that  precede  them  in  the  depth  first  ordering,  This  is  used 
to  instantiate  the  lower  level  goals.  For  example,  suppose  Q(b)  a  P( a)  is  a  condition  to 
be  achieved  and  a  primitive  procedure  R(y)  a  P(x)  (p(x,y)}Q(y)  is  applied  to  achieve 
Q(b),  then  for  the  P(x)  in  .the  precondition  of  p,  P(a)  will  be  used  since  it  must  be 
achieved  at  the  higher  level  anyway,  i.e., 
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/  \ 

/  \ 

Q(b)  P(a) 

/  \ 

/  \ 

R(b)  P(x)(<x<-a>) 

This  heuristic  may  be  viewed  as  ths.  opposite  of  subsumption,  the  strategy  being  to  get 
ground  instances  ss  soon  as  possible  to  help  avoid  long  searches  using  rules.  This  is  a 
rather  restrictive  strategy  that  may  exclude  solutions  and  is  only  used  when  requested 
by  the  user. 

(10)  Evaluation  of  Predicates  and  Functions.  For  certain  predicates  occurring  in 
subgoals,  achievement  is  most  efficient  by  direct  evaluation.  If  a  literal  occurring  in  a 
goal  is  formed  with  a  predicate  that  has  a  LISP  definition,  then  that  literal  is  evaluated 
as  a  LISP  statement.  Special  processes  or  even  subsystems  ran  thereby  be  linked  into 
program  generation.  Evaluation  of  arbitrary  functions  occurring  in  terms  in  arguments  of 
goal  literals  is  done  if  the  function  occurs  in  the  scope  of  an  EV  modifier.  These 
evaluations  assume  the  soundness  of  implicit  axioms  describing  the  LISP  definitions,  and 
the  consistency  of  these  axioms  with  the  Frame.  For  example,  the  equality  predicate, 
"=",  is  evaluated  using  the  LISP  "EQUAL",  and  the  predicate  NEWVAR(xl,x2,...,xn)  takes 
an  arbitrary  number  of  arguments  and  binds  each  Frame  variable  xi  to  a  new  program 
variable  (for  use  perhaps  as  a  local  variable  in  a  block). 

(11)  Simplification  rules.  Rules  of  the  form  s  ->  t  where  s  and  t  are  terms,  may  be 
included  in  the  Frame.  Such  rules  are  applied  to  simplify  terms  hi  goals  by  replacing 
occurrences  of  Soc  by  tec.  This  not  only  reduces  the  complexity  or  terms  in  the  subgoal 
tree,  but  it  also  modifies  the  pattern  matching  process  and  the  set  of  rules  that  can  be 
applied  to  reduce  a  goal. 

(12)  Computing  Input/Output  Assertions.  In  Section  2  primitive  procedures  were 
viewed  as  Frame  rules  of  the  form  P{p}Q,  where  P  and  Q  are  the  pre  and 
postconditions  for  p.  The  conditions  P  and  Q  may  also  be  viewed  as  sufficient  input  and 
output  assertions  for  p  ,  that  must  be  satisfied  by  the  actual  parameters  of  p.  For  any 
generated  program  segment  A,  the  input  assertion  lA  is  computed  as  the  conjunction  of 
all  literals,  I,  from  a  state  that  were  used  in  achieving  subgoals  encountered  during  the 
generation  of  A  and  did  not  occur  in  that  state  as  a  result  of  a  postcondition  of  a 
procedure  whose  generation  in  A  preceded  the  addition  of  I  to  lA.  The  output  assertion 
0A  is  the  conjunction  of  literals  added  to  a  state  during  the  generation  of  A  that  are 
true  in  the  final  state. 

The  usefulness  of  computing  sufficient  input  and  output  assertions  for  a  program  or 
segment  thereof  will  become  apparent  when  we  discuss  program  generalization  and  the 
construction  of  conditional  statements. 

All  of  these  applications  of  facts  and  advice  with  the  exception  of  (12),  are  intended  to 
have  a  direct  effect  on  reducing  the  growth  of  the  subgoal  tree  (process  (b)).  In 
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addition,  the  pattern  matching  process  (a)  is  extended  by  < 1 1);  (c)  is  aided  by  the 
restriction  of  truth  values  and  the  special  axioms  (6,8);  (e)  is  dependent  on  (6  and  12); 
(f)  is  aided  by  (3,7,11,12).  There  are  other  techniques,  mainly  details  of  the 
implementation,  some  of  them  heuristic,  that  affect  problem  solver,  particularly  the 
backtrack  (d),  the  updating  (c)  and  assembly  of  programs  (f)  (e.g.  the  Implementation  of 
the  a  connective  by  software  interrupts  that  protect  already  achieved  goals,  includes 
certain  assumptions  about  backtracking  when  an  AND-node  fails).  Details  of  these  will 
be  found  in  [Buchanan  1974]. 
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5.  GENERATION  OF  CONDITIONAL  STATEMENTS 


Conditional  statements  are  generated  in  situations  where  the  rule  of  undetermined 
values  applies  or  when  the  outcome  of  a  primitive  procedure  Is  uncertain.  In  this 
section  the  system  methods  for  constructing  conditionals  will  be  described  and  an 
example  given.  The  question  of  extending  the  formal  algorithm  and  the  correctness 
proof  is  considered. 

5.1  UNCERTAIN  PRECONDITIONS.  As  previously  mentioned,  relations  involving  partial 

predicates  may  have  truth  values  of  TRUE,  FALSE,  or  UNDETERMINED,  whereas  all  other 
relations  must  be  either  TRUE  or  FALSE.  Partially  valued  predicates  are  intended  to 
express  the  possibility  of  an  uncertainty  or  lack  of  knowledge  about  a  state  arising 
during  the  problem  solving  and  program  generation  phase  of  the  system.  The  formal 
algorithm  for  deciding  when  an  uncertainty  has  arisen  is  rule  R6  (the  "I  give  up" 
criterion  of  the  system).  As  with  invariance,  the  implementation  of  R6  is  only  an 
approximation  to  the  formal  rule  The  system  may  give  up  too  early,  but  this,  in  itself 
does  not  lead  to  incorrect  programs,  merely  redundant  ones.  ! 

5.1.1  UNDETERMINED  VALUES.  During  the  generation  of  a  program,  uncertainty  may 

arise  when  a  precondition  for  the  application  of  a  rule  is  UNDETERMINED  with  respect 
to  the  current  state.  The  implementation  of  the  rule  R6  is  described  by  the  following 
definitions:  5 

DEFINITION  A  literal  I  is  UNDETERMINED  in  a  state  S  if  the  following  conditions  hold: 

(i)  pred(l)  is  partial, 

and  (ii)  the  system  halts  without  solving  S{?}l, 
and  (iii)  the  system  cannot  prove  SUF:H. 


Condition  (ii)  means  that  I  is  not  true  in  S  nor  can  S  be  transformed  into  a  state  in 
which  I  is  true.  If  condition  (ii)  is  true  and  ->1  is  true  in  S  then  I  must  retain  a  truth 
value  of  FALSE  and  the  precondition  subgoal  I  must  fail.  Failure  to  prove  ->1  from  S 
establishes  a  truth  value  of  UNDETERMINED  for  I  with  respect  to  S.  This  definition 
applies  to  fluent  and  nonfluent  literals  but  since  the  truth  value  of  a  "nonfluent"  cannot 
be  changed  by  a  state  transformation,  for  them,  it  is  sufficient  to  use  only  the  logical 
axioms  in  deciding  condition  (ii). 

For  the  more  general  case  in  which  the  precondition  may  be  a  disjunction  of  literals  we 
have  the  definition, 

DEFINITION  A  disjunction  of  literals  {I,  }»M  is  UNDETERMINED  in  a  state  S  if  at  least  one 
literal  is  UNDETERMINED  and  no  literal  can  be  achieved  from  S. 

5.2  CONDITIONAL  STATEMENTS:  When  a  pre-condition  P  is  UNDETERMINED  in  a  state  S, 
a  conditional  branch  is  inserted  in  the  solution  program.  If  P  is  a  single  literal  I,  then 
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nroeram  generation  may  continue  either  along  the  path  in  which  I  is  assumed  to  be 
TRUE  and  in  which  future  goals  are  attempted  with  respect  to  state  S  U{l},  or  along  the 
loth  in  which  n|  is  assumed  to  be  TRUE  using  state  S  UH).  The  system  convention  has 
u  t  a  call  to  a  yet  ungenerated  procedure  for  the  latter  case,  The  tasks 

of^e  eS  such '  contingency  programs  are  placed  in  a  subproblem  stack  for  later 
ttfntinn  (cee  section  5  3).  Program  generation  continues,  by  convention,  along  the 
state SUM  This  path  is  referred  to  as  n.  "trunk"  program  of  the  tree  o 
contingency  programs  generated  while  attempting  to  achieve  the  main  goal.  The  path 
Sfon  at  present  is  rather  ad  hoc  since  no  assignments  of  probability  are  made  at 
the  po°nts  of  uncertainty  and  no  path  is  considered  more  likely  to  be  successful  In 

general. 

If  an  undetermined  disjunctive  precondition  {I,  occurs  in  which  literals  {I,  men 
are  UNDETERMINED  in  S,  then  a  nested  conditional  of  the  following  form  will  be 
generated; 

if  i|,  then 
If  -.1,  then 


if  -lm  then  pffl 
else  Pm_, 


'  else  Pi 
else  p0 

where  each  Pj  is  a  call  to  a  program  to  achieve  ti  selected  goal  G  from  state  S,  =  S  U  {l( 

•  i=i+l  &  i<m  }  U  Hi  :  l<i<j}  }  and  p0  is  tho  trunk  program  segment  which  satisfies 
cA|  (D  }G  and  forms  the  else-statement  in  the  main-clause  of  the  conditional,  Each 
member  of  the  set  of  triples  {<P,  ,  S,  ,G>:  Uj<m  }  is  placed  in  the  stack  o, 
contingencies  and  program  generation  continues  for  p„.  The  assumed  literal, I  „  is 
removed  from  the  state  following  the  generation  of  the  ELSE  clause  in  the  trunk 
program  if  it  is  not  in  the  output  assertion. 

5  3  SELECTION  OF  CONTINGENCY  GOAL  The  goal  G  to  oe  achieved  by  the  contingency 
programs  is  selected  from  the  set  of  gods  in  the  subgoal  tree  that  are  global  to  he 
undetermined  precondition,  let  us  refer  to  the  set  of  goals  which  are  below  G  in  the 
subgoal  tree,  as  the  SCOPE  of  G. 

The  particular  G  chosen  and  its  associated  scope  affect  the  length  of  p„  ,  duplication 
na  rnnti neenev  programs,  degree  of  difficulty  in  generating  contingency  programs 
vliiditv  ofthe^ruse2  If  the  structure  of  the  trunk  program  is  to  remain  fixed  during 
contingency  prirem  generZn  then  the  choice  of  G  cannot  be  deferred.  The  block 
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structure  of  our  program  language  imposes  the  restriction  that  for  any  conditionals  in 
p0,  a  contingency  goal  G’  must  not  have  a  greater  scope  than  G.  There  is  also  the 
problem  that  if  G  is  not  fully  instantiated  (i.e.  some  of  its  variables  are  not  in  the  initial 
state)  then  inconsistent  instantiations  may  occur  in  different  contingency  programs  which 
must  validly  rejoin  the  main  program  following  the  ELSE  clause.  The  present  system 
selects  the  least  global  fully  instantiated  goal  thereby  satisfying  the  block  nesting 
constraint  and  minimizing  the  scope  while  avoiding  the  problem  of  handling  deferred 
instantiation.  This  selection  process  is  always  effective  in  the  present  system  since  the 
top  level  goal  is  fully  instantiated, 


5.4  REJOIN  CONDITIONS:  When  a  contingency  program  is  generated  its  output  state 
must  satisfy  certain  conditions,  hereafter  called  the  rejoin  condition,  for  return  of 
control  to  the  trunk  program  to  be  correct.  Consider  the  case  of  an  undetermined  goal 
L  in  state  S  and  a  contingency  goal  G  in  Figure  8  .  Let  A  and  B  be  program  segments 
that  satisfy  S  a  L{ A }G  and  S  a  ->L{B}G  and  let  C  be  the  rest  of  the  trunk  program. 


Figure  8 


Let  R  be  the  output  state  of  B  obtained  by  applying  invariance;  thus  Sa->L{B}R  and  RdG 
Similarly,  let  SaL{A}P  where  P=>G,  and  let  Q  be  the  minimal  subset  of  P  required  as 
input  to  C  (section  4(12)),  Then,  the  REJOIN  CONDITION  for  B  is  R=>Q.  B  is  said  to  have 
BAD  SIDE  EFFECTS  if  in  fact  R^Q  cannot  be  established. 


5.5  SUBPROBLEM  STACK:  The  task  of  generating  a  contingency  procedure  is  specified 
by  the  quadruple: 
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(<procname>  <state>  <goal>  <rejoincond>) 
where, 

<procname>  is  the  name  of  the  yet  ungenerated  procedure  that  must 
satisfy  <state>{<procname>}<gosl>  a  <rejoincond>. 


At  the  point  in  the  planning  when  the  uncertainty  is  encountered,  the  first  three 
elements  of  the  quadruple  are  placed  in  a  stack.  The  rejoin  condition  is  not  known  at 
this  time  since  it  involves  the  input  assertion  for  the  trunk  segment  C  following  the 
point  where  control  returns  from  the  contingency  plan  to  the  trunk  plan.  After  C  is 
generated,  the  rejoin  condition  is  computed  and  stored  as  the  fourth  element  of  the 
quadruple. 

When  planning  has  been  completed  for  a  trunk  procedure,  if  the  subproblem  stack  is 
not  empty  then  contingency  planning  may  be  done  by  removing  a  quadruple  from  the 
stack  and  posing  this  as  a  program  generation  task.  The  state  of  the  system  is 
initialized  to  the  specified  contingency  state  and  the  subgoaling  system  is  given  <goal> 
as  its  main  goal.  If  it  is  successful  in  achieving  a  state  in  which  the  main  goal  is  true 
then  a  test  is  made  to  see  if  the  rejoin  condition  is  true  in  that  state.  If  it  is  then  the 
procedure  declaration  is  adjoined  to  its  trunk  program.  If  the  condition  cannot  be 
proved,  the  system  allows  the  user  two  alternatives:  (i)  Mark  the  call  to  the  program  as 
an  error  exit  in  the  trunk  program,  or  (ii)  "Fit"  the  program  to  the  trunk  program  by 
posing  the  currently  untrue  rejoin  condition  as  a  new  goal,  constructing  a  new  program 
segment  that  achieves  it,  and  appending  this  segment  to  the  end  of  the  contingency 
program. 

This  process  of  generating  a  trunk  procedure  which  may  create  new  contingency  tasks 
then  generating  contingency  procedures  as  directed  by  the  user  may  continue  until  all 
contingencies  have  been  processed  and  the  stack  is  exhausted. 

5.6  COMPUTATION  OF  INPUT/OUTPUT  ASSERTIONS  The  computation  of  input/output 
assertions  for  programs  not  containing  conditionals  is  described  in  Section  4(12).  The 
uncertainty  as  to  which  path  computation  will  follow  in  a  program  containing  conditional 
statements  complicates  these  assertions.  The  input/output  assertions  in  this  case  must 
be  computed  incrementally  as  each  contingency  program  is  generated. 

In  the  conditional  statement  shown  in  Figure  8,  suppose  we  know  the  minimal  input  and 
output  assertions  for  A  and  B,  say  P{A}Q  and  R{B}S.  then  the  input  and  output 
assertions  for  the  conditional  statement  are 

(L  a  P)  v  (-1  a  R){if  L  then  A  else  B}Q  v  S. 

To  reduce  computation,  We  use  the  simpler  sufficient  input  assertion  P  a  R,  (Note  that 
P  a  R  should  be  consistent  since  it  is  a  subconjunct  of  a  previous  state).  There  doesn’t 
appear  to  be  a  simplifying  approximation  for  output  assertions  , 
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5.7  UNCERTAIN  PRIMITIVE  PROCEDURES:  A  primitive  procedure  q  defined  by  P{q}Q 
has  an  uncertain  outcome  if  Q  is  a  disjunction.  In  the  present  system,  disjunctive  post¬ 
conditions  use  the  exclusive  OR  connective,  "®".  This  allows  us  to  define  frame 
procedures  that  have  an  intended  result  but  may  be  unreliable.  It  Is  assumed  that 
exactly  one  of  the  possible  outcomes  will  be  true  in  the  output  state.  At  the  point 
where  an  uncertain  operator  it  applied,  the  problem  solver  has  *tc  knowledge  of  what 
the  outcome  will  be  and  a  conditional  statement  must  be  generated.  Let  Q  be  the 
disjunction  of  literals  {IJ*,,.  The  first  outcome  I,  is  considered  to  be  the  normal  (goal) 
result  at  ex^cuti-tg  q  Following  thr.  inclusion  cf  q  in  the  program  in  stele  5,  a 
conditional  statement  of  the  following  form  is  generated: 


if  ->  I ,  then 


if 


A 


■2 


A 


lg  A. ..A  ->  ln 


else  if  -i  I,  a->I?  a  |. 


A 


then  p2 

I  l4  A, ..A  -1  ln 


then  p3 


else  if  -  I,  a  1  l2  a,..a  ln_,  a  ln  then  pn 
else  pn 


"n«  I 


where  each  p,  ,  2  <  i  <  n,  is  a  call  to  a  program  to  achieve  I,  from  state  S,  =  S  U  {I,  }  U 
{->  Ij  :  j  ?  i  &  1  <  j  <  n},  and  pn<l  is  an  error  exit.  The  contingency  states  will 
correspond  to  the  n  ways  of  assigning  exactly  one  literal  true  and  the  remaining  literals 
false. 


5.8  AN  EXAMPLE  Suppose  a  procedure  is  to  be  generated  for  a  man  to  travel  from  San 
Francisco  to  New  York  given  three  modes  of  travel,  i.e.,  flying,  driving,  or  walking.  This 
is  similar  to  the  "airport  problem"  discussed  in  [McCarthy  1959].  A  FRAME  for  this 
problem  consists  of  defining  a  primitive  procedure  for  each  mode  of  travel,  an  initial 
state,  and  relation  information  as  shown  in  Figure  9.  A  few  of  the  contingency  programs 
generated  are  shown  in  Figure  10. 
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relations _ 

ROI1  X) 

AUTO.  X) 

PIANE  X) 

AIRPORT  X'l 

AT.X.Yl 

WA  UNABLE  X ,  Y ) 

CLEAR  X,Y' 
DR1VAIU.E  X.Yl 

IIASt’MIlREI.LA  X) 
CRASHED  X.Y.Zl 
KILLED  X) 

RUNS  X’l 
ELIES  X) 


DEFINITION _ _ _ 

"X  Is  a  robot." 

"X  is  an  automobile" 

"X  is  an  airplane" 

"X  is  an  airport" 

"X  is  at  location  Y" 

"A  walkable  pa-h  exists  between 
X  and  Y" 

'The  sky  is  clear  between  X  and  Y" 

“A  drivable  road  exists  between 
X  and  Y" 

"X  has  an  umbrella" 

"X  crashed  between  Y  and 
"X  has  been  killed" 

"X  will  run  properly" 

"X  i ill  fly  properly" 


ELUENT 

PARTIAL 

UNIQUENESS 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

FALSE 

IAI.SE 

FALSE 

TRUE 

FALSE 

AT ; x ,  • ) 

TRUE 

TRUE 

FALSE 

TRUE 

TRUE 

FALSE 

TRIE 

TRUE 

FALSE 

TRUE 

TRUE 

FALSE 

TRUE 

FALSE 

FALSE 

TRUE 

FALSE 

FALSE 

TRUE 

TRUK 

FALSE 

TRUE 

TRUE 

FALSE 

PRIMITIVE  PROCEDURE _ 

walk  Rl.1.1,1.'  1 

"Rl  walks  irom  LI  to  I. 


dr  ive  Rl  ,C1 ,  LI ,  I*  ) 

"Rl  drives  Cl  lrom  1,1  to  1. 


llyiRl.Al, 1.1.1.  ' 

"Rl  (lies  A 1  from  1.1  to  L  " 


PRE-CONDITIONS  _ 

ROH-'Rl)A-i  KILLED! Rl )AAT  ( R 1 ,  LI ) 
ACLEARiLl.L'  1VI1ASUMI1RELIA  Rl) 
AWA  UNABLE  LI, I.’)! 

ROB  R 1 ) A-.  K 1  LI.ED  R 1  )AAIJT0  Cl) 

AT (Cl ,L1)ARUNS(C1 ) 

ADR  I VA BLE  1.1 ,1.  )a AT ;  Rl  ,1.1) ; 

ROB  R 1  )A— >  KILLED  Rl)A PLANET Al) 

aairport  l:  )aat  ai,i.i) 

ALLIES  A1)ACI.EAR  1.1,1.  ) 

AAT  R  1,1.1); 


POST-CONDITION'S 
AT  ( R 1 , 1.  ) 


AT  R 1 , L  ) 
AAT  {Cl,  1.  ) 


AT  Rl , L  )A 
AT  A  1,1.  )| 

2'  CRASHED  Al,  1.1,1. 
AKILLED.Rl); 


INITIAL  STATE 

AN'AAITO  BMIClAPIANE  FI  1 1  )AA  I R PORT  SEO' AAIRPORT  NYC) AAT  MAN, HOME  \AT  BFto’,  GARAGE  )AAT’  Fill  ,SFO  /  I 


PAIRWISE  INEQUALITIES: 
TRY  ELY  BEFORE  DRIVE, 


ADVICE 

walk  Rl ,  * ,  *  ^  ,clr ive  R 1  ,Cl ,  '  ,  * ' ,  t  Lv  R 1 ,  A  l , 
TRY  DU  IVE  BEFORE  WALK 


Figure  9 
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■X. 


Fund  man  nyc 

ROB  MAN  ;AIT0  R.'K  ;PIANE  1111  ;AIRFUR1  NYC  : 

COMMENT 

1NPCT  ASSERTION: 

AT  MAN  HOME  'CLEAR  HOME  CARAGE  'AT  BMW  (AKACE  AI  I  111  Sin 
ATI. IKS  Till  'CLEAR  S10  NYC  aRC.NS  HMJ 
\  DR  1  CABLE  CARAGE  STO  'UAI.KARI.E  HOME  (AKACE 
OCT  PET  ASSERTION: 

AT  BMW  STO  'AT  Till  NYC  'AT  H\N  NYC  ; 

COMMENT 

PROCll  ATTEMPTS  _TO_ACII  I  EVE_  AT  MAN  NTl 
PROCl  A. TEMPTS  TO  ACHIEVE-  AT  M\N  (ARAM 


PROC 

PROC 


ATTEMPTS, 

_TO_AC!!IHVK_ 

AT 

MA : 

(■AKA!  i: 

ATTEMPTS 

"to  j\cii  i  eve” 

AT 

ha: 

('•AKACE 

ATTEMPTS 

”to~achii:ve" 

AT 

MA . 

SI  U 

ATTEMPTS 

~T0_ACI1IEVK_ 

at  ma 

sin 

ATTEMPTS 

JTO_ ACHIEVE 

AT 

MA  ■ 

:.*YG 

ATT  EM  ITS 

~TO  ACHIEVE- 

AT 

M\:; 

.\TC  ; 

T  HEN 


PROC 

BEG  111 

IT  -ELIES  Fill  THEN 
PROC  MAN  NYC 
ELSE 
BEGIN 

IE  “CLEAR  SIO  NYC 
PROC;  MAN  NYC 
ELSE 

BEGIN 

IT  “REMS  BMC  THEN 
PROC-  MAN  STO 
ELSE 
BEGIN 

IF  “ l)R  1VABI.E  GARAGE  SIO  THEN 
PROC-  MAN  SIO 
ELSE 

BEGIN 

II  -CLEAR  HOME  GARAGE  THEN 
IF  “IIASIMIIRELIA  MAN  THEN 
PROC.  MAN  (AKACIE 
ELSE  PROC  MAN  GARAGE 
ELSE 

BEGIN 

I  E  —  WALKA  BLE  HOME  GARAGE 
PROCl:  MAN  CARAGE. 

EI.SE 

BEGIN 

WALK  MAN  HOME  GARAGE 
END 

END 

DRIVE  MAN  BMC  GARAGE  SIO. 

END 

END 

ELY  MAN  Fill  SIO  NYC 
II  —AT (MAN  NYC)  Til..:. 

II  -AT  CAN  NYC)  A  CRASHED  {Till  STO  NYC) 
iVOCl  I  CAN  ,.YC) 

ELSE  PROC  INI  i  MAN  NYC) 

..END 


THEN 


E  ND 


NT) 


PROC  FLAN  NYC  1 
ROB  MAN' ;ACTO  BMW  ; 

C.OFL'IENT 

I  MPIT_ASSERT10N: 

AT  MAN  HOME  'CLEAR  HOME  GARAGE  AAT  ,  BMW  CARNAGE  ' Rl’NS  BUT 
A  DR  I VA  lil.l.  (ARAGE  NYC  AWALKA  BLE  .  HOME  CARAGE 


Figure  10a 
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OUT PUT_  ASSERT l ON: 

AT  BEW  NYC)AAT(MAN  NYC); 

COMMENT 

PKOCU  ATTEMPTS_TO_ACHIEVE  AT  MAN  GARACE) 
PROC15  ATTEMPTS_T0_ACH1EVE_  (AT  MAN  GARACE) 
PROCll*  ATTEMm_TO_AClllEVH_  (AT  MAN  GARAGE) 
PROC1J  ATTEMPTS_TO_ACH  1EVE_  (AT  MAN  NYC) 
PROC 12  ATTEMPTS_TO_ACIl  IEVF,_  AT  MAN  NYC); 
BEGIN 

[RERUNS  MW)  THEN 
PROC li? (MAN  NYC) 

ELSE 

BEGIN 

IF  -iDRIVABLE  .GARAGE  NYC)  THEN 
PROCl'.cMAN  NYC) 

ELSE 

BEGIN 

II  -.CLEAR  HOME  CARACE)  THEN 
IF -HIAS UMBRELLA  FAN)  THEN 
PROC  1 . 1  MAN  GARAGE) 

ELSE  PROC  1),  'MAN  GARAGE) 

ELSE 

BEGIN 

1 F  -.WALKA11LE •  HOME  GARACE)  THEN 
PROC16  (FAN  GARACE) 

ELSE 

BEGIN 

WALKMAN  HOME  GARAGE); 

END 

END 

DRIVE;. MAN  BMW  GARAGE  NYC) 

END 

END 

END 


PKOCU 1  FAN  SEO) 

ROB:  MAN' ; 

COMMENT 

ATPMA?f  'llOMEJACLEAR  HOME  SEO)AWALKAIILE  HOME  SEO) 
OUTPUT  ASSERTION: 

AT  MAN  SFO) ; 

COMMENT 

PROC  ,  ATTEMPTS_TO_ACIIIKVK_  AT  'AN  SEO 
PROC  ATTEMPTS JT0_ACHIEVE_  AT  'AN  SFO 
PROC  ATTEMPTS J()_ACII  1  EVU_  AT  'AN  SFO); 

BEGIN 

IE  -.CLEAR  HOME  SEO  I  IIEN 

IF  -.lASUMBRELlA  FAN)  THEN 
PROC.  yMAN  SEO  : 

ELSE  PROC  .  'AN  SEO 
ELSE 

BEGIN 

IE  — .WALKAHLE  HOME  SEO  THEN 
PROC.  r-  'AN  SFO' 

ELSE 

BEGIN 

WALK  MAN  HOME  SEO 
END 

END 

END 

PROCL  'AN  NYC 
ROB  'AX'; 

COMMENT 

INPUT  ASSERTION: 

AE  MAN  HOME'  > CLEAR  HOME  NY C ) t WA LKA BLE ( HOME  NYC., 


Figure  10b 
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5.9  CORRECTNESS  The  formal  algorithm  of  Section  2.3  can  be  extended  to  include  the 
case  when  G’  is  undetermined  in  P  by  formalizing  a  simplified  version  of  the  system 
methods  described  above.  We  shall  mention  some  of  the  pertinent  details  here. 

The  extension  requires  formalizing  the  subproblem  stack  and  the  methods  of  choosing 
contingency  goals.  Also,  it  is  necessary  to  add  clauses  for  assembling  conditional 
statements  into  the  answer  A  according  to  rule  R5,  Thus  contingency  goals  must  be 
"marked"  and  the  appropriate  undetermined  subgoals  associated  with  them,  so  that 
when  a  contingency  goal  is  achieved  during  the  generation  of  the  trunk  program,  the 
related  conditionals  are  assembled  into  A.  The  computation  of  the  state  l(n)  must  be 
modified  when  G(n)  is  the  contingency  goal  for  G(i)  by  removing  G(i)  if  it  is  not  in  the 
output  assertion  of  the  program  segment  generated  between  achieving  G(i)  and  G(n). 
We  do  not  justify  the  system  method  of  computing  input  assertions,  and  instead  assume 
that  in  the  formal  algorithm  the  state  at  any  node  in  the  subgoal  tree  is  the  input 
assertion  for  the  following  segment  of  the  generated  program. 

To  extend  the  correctness  proof  of  Section  2.5,  we  must  extend  the  induction  step  to 
include  the  cases  when  (a)  G(n+1)  is  undetermined  in  l(n),  and  (b)  G(n+1)  is  achieved 
from  l(n)  and  is  the  contingency  goal  for  G(i),  say,  where  i<n+l.  The  induction 
hypothesis  must  be  modified  to  take  account  of  any  undetermined  goals  (assumed  true 
in  the  trunk  program)  whose  contingency  goals  have  G(n)  within  their  scope.  Thus, 
typically,  the  hypothesis  would  be  l{A(i)}l(i)  and  l(i)AG(i){A(i,n)}l(n),  where  G(i)  is 
undetermined  in  l(i)  and  has  a  contingency  goal  more  global  than  G(n),  and  A(i,n)  denotes 
the  program  segment  generated  between  achieving  G(i)  and  G(n). 

Case  (a):  G(n+1)  is  achieved  by  assumption  in  generating  the  trunk  program, 
l(n+l)=l(n)AG(n+l)  and  A(n+l,n+l)  is  empty. 

Case  (b):  let  B  be  the  contingency  branch.  Tha  previous  proof  implies  that 
l(n+l)=>G(n+ 1).  We  also  have  that  A(n+1)  =  A(i);IF  G(i)  THEN  A(i,n+1)  ELSE  B. 


(1)  l{A(i)}l(i),  hypothesis, 

(2)  !(i)  a  G(i){A(i,n+l)fl(n+l)  hypothesis 

(3)  l(i)  a  ->G(i){B}F(n+l)  assumption, 

(4)  |’(n+l)=>l(n+l)  rejoin  condition, 

(5)  l(i) {IF  G(i)  THEN  A(i,n+1)  ELSE  B}i(n+1)  R5,2,  Rl,3,4 

(6)  l{A(n+l)}l(n+l)  and  l(n+l)  =>  G(n+1)  R2,l,5. 


The  proof  of  !{A(m)}G  follows  by  noting  that  all  contingency  goals  must  have  been 
achieved  when  the  final  goal  G  is  achieved. 


6.  GENERATION  OF  ITERATIVE  STATEMENTS 


An  iterative  rule  allows  the  program  generator  to  construct  a  WHILE  loop  provided  it 
can  construct  a  loop  body  to  satisfy  the  premisses  of  the  rule.  Ultimately  such  rules 
should  require  the  user  merely  to  specify  an  invariant  in  order  to  have  the  system 
write  a  correct  iterative  program.  At  the  moment,  the  user  needs  to  furnish  some 
additional  relevant  facts.  The  algorithms  used  in  the  system  to  implement  iterative 
rules  of  the  form  S2  (Section  2)  and  to  assemble  while  loops  are  described  briefly  and 
an  example  given. 

6.1  PREMISSES  FOR  CONSTRUCTING  A  LOOP:  An  iterative  rule  is  defined  by  the 
assertions  P(basis),  Q(loop  invariant),  R(iteration  step  goal),  Gfrule  goal),  Lfcontrol  test) 
and  S(output  assertion).  All  the  free  variables  in  R  and  L  must  be  among  the  free 

variables  in  Q.  In  order  to  use  the  rule,  to  achieve  l{?}G  say,  the  formal  algorithm 

requires  that  all  of  the  following  subgoals  be  achieved  or  be  true: 

(i)  Construct  A  such  that  L(F)||-  l{A}P 
<ii)  L(F)|-  I { A }Q 

(iii)  Construct  B  such  that  L(F)||-QaL{B}R 

(iv)  L(F)  |-  QaL{B}(3Z)Q(Z)vH3Z)Q(Z)a  .L  ) 

(v)  Construct  C  such  that  L(F)  ||-  QaL{B;C}Qv-L 

Note  that  (ii)  and  (iv)  are  restricted  to  first  order  rules  (consequence,  invariance,  and 
the  frame  axioms).  The  input  state  for  (iii)  is  QaL.  In  addition,  an  iterative  rule  must 
satisfy  the  following  minimal  consistency  requirements  within  the  frame  F: 

(vi)  ->(S  U  F  =  L)  and  S  U  F  =>  0. 

The  conclusion  of  the  rule  is:  l{ AjWHILE  L  DO  BEGIN  B;C  END}G. 

Iterative  frame  rules  are  instances  of  the  iteration  rule  [Hoars  1969]: 

QaL{ A]Q,  Qa-LoG 


Q{WHILE  L  DO  A}G  . 

It  is  possible  to  derive  a  weak  form  of  the  rule: 
QaL{A}Qv-iL,  -iL^G 


Q- WHILE  L  DO  A }G  . 


The  weak  form  allows  the  invariant  to  fail  on  exit  from  the  loop.  We  have  found  the 
weak  form  convenient  to  use  in  many  examples. 

The  present  implementation  sets  up  clauses  (i)  -  (iv)  as  a  THAND  of  subgoals  to  be 
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achieved.  More  specifically,  suppose  an  iterative  rule  is  invoked  to  solve  the  problem 
|{?}G,  Let  V  be  the  list  of  variables  in  Q.  The  system  does  the  following: 

(1)  A  program  segment  p(P)  is  generated  such  that  l{p(P)}l  and  I  UF  |-  P  (  note 
that  p(P)  may  be  empty). 

(2)  An  instance  QX  of  the  loop  invariant  must  be  true  in  the  state  I’,  i.e.  X  =  {<v, 

<_  S)  >,...,<vn  «-  sn  >}  is  constructed  such  that  I’UF  =  QX. 

(3)  A  program  segment  p(R)  is  generated  such  that  Q  a  L{p(R)}l  and  I  UF  ^  R. 

(4)  It  is  checked  that  f'UF  =  Q/Sv-L/?  for  some  substitution  (l  and  a  set  of 
conditional  assignment  statements  C  is  constructed  such  that  l"{C}Q  v  -L. 

Thus  at  the  moment,  clause  (iv)  ensures  that  C  need  contain  only  conditional 

assignments.  In  the  future  we  would  want  to  relax  this  restriction.  It  is  assumed  that 

the  user’s  definition  of  the  rule  satisfies  (vi).  The  user  may  omit  S  or  L;  in  the  latter 
case  ■>  G  is  used  as  the  control  test. 

6.2  ASSEMBLY  OF  WHILE  LOOPS:  After  the  premisses  have  been  achieved,  a  loop  is 
assembled  as  follows: 

(1)  Let  Y  and  W  be  two  distinct  lists  of  variables  in  one-to-one  correspondence 

with  V.  For  each  <v,  <-  s,  >  (  X  construct  an  initial  assignment  statement  "yi  *•  s,  ". 

Let  "Y  «-  S"  denote  "yi  *-  s,  ;  y2  <-  s2 ; .  .  y„  sn 

(2)  The  WHILE  loop  is  then  assembled  in  the  form: 

p(P); 

Y  <-  S; 

WHILE  L(Y)  DO 
BEGIN 
p(R(Y»; 

IF  Q(W)  THEN  Y  <-  W; 

END 

whpre  O(W)  is  an  expression  containing  calls  to  Boolean  procedures  indicated 
(syntactically)  by  the  presence  of  the  special  W-variables  (Section  2,  Rule  RO).  Q(W) 
is  constructed  from  Q(V)  by  replacing  V-variables  by  corresponding  W-variables; 
p(R(Y))  is  obtained  in  a  similar  way  from  p(R(V)).  Since  the  variable  lists  are  disjoint, 
none  of  the  Y-variables  occurs  in  Q(W), 

There  are  many  heuristics  in  the  system  to  reduce  the  number  of  program  variables,  i.e. 
y’s  and  w’s  generated,  to  select  the  relevant  portion  of  Q  to  be  used  in  conditional 
assignment  statements,  to  generate  simple  assignment  statements  (whose  right  hand 
sides  are  functional  terms  composed  from  functions  in  the  frame)  instead  or  conditional 
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assignments,  and  to  eliminate  unnecessary  assignment  statements  in  the  assembled 
program.  These  may  all  be  classified  as  optimizations,  some  of  which  are  done  as  the 
WHILE  loop  is  assembled  and  others  during  a  later  optimization  phase. 

6.3  UPDATING  THE  STATE;  After  the  while  statement  has  been  generated,  the  system 
updates  the  state.  If  an  explicit  output  assertion  S  is  given  then  the  rule  of  invariance 
is  applied  in  the  same  manner  as  with  the  postcondition  of  a  primitive  procedure,  In  the 
absence  of  an  output  assertion,  a  special  update  procedure  runs  the  loop  interpretively 
on  the  state  until  the  goal  G  becomes  true.  The  resultant  state  is  used  in  further 
planning.  This  latter  method  is  useful  when  the  global  effects  of  the  loop  computation 
are  so  extensive,  or  even  unpredictable,  that  an  explicit  specification  of  S  is  difficult.  It 
may  result  in  excessive  update  computation,  particularly  when  loops  are  nested. 

6.4  CORRECTNESS:  We  sketch  how  the  basic  correctness  proof  of  the  formal 
algorithm  (section  2.5)  may  be  extended  to  the  case  where  iterative  rules  are  used  to 
develop  nodes  in  the  successful  subgoal  tree.  This  requires  that  we  supply  the 
argument  for  this  extra  case  in  the  induction  step  of  that  proof. 

Let  node  G(n+1)  be  developed  using  an  iterative  rule,  and  assume  first  that  this  is  the 
only  iterative  rule  used.  To  simplify  the  notation,  we  shall  assume  that  the  matching 
substitution  between  the  rule  goal  G  and  G(n+1)  is  the  identity,  i.e.  G=  G(n+1)  A  G\ 

It  is  convenient  to  view  G(n+1)  as  being  the  root  node  of  a  THAND  subtree  (see  e.g. 
figure  3,  Section  2.3).  The  immediate  subgoals  of  G(n+1)  are  (i)  to  (iv)  above  (6.1). 
Suppose  that  the  last  node  to  be  achieved  in  the  main  tree  is  G(n),  the  associated  state 
and  program  being  l(n)  and  A(n)  respectively.  The  induction  hypothesis  is  l{A(n)}l(n). 

Let  us  abbreviate  "IF  Q(W)  THEN  Y*-W"  by  C.  In  the  successful  subgoal  tree,  the 
subgoals  of  G(r,+  1)  are  all  achieved  so  that  we  have 

1.  l(n)'|p(P)}l(n)’  where  l(n)’  U  F  s  P  and  l(n)’  U  F  =>  Q  \ 

(subgoals  (i)  and  (ii)), 

2.  Q\{Y~S}Q(Y)  by  the  assignment  axiom,  RO. 

3.  Q(Y)AL(Y)jp(R)}l(n)"  where  l(n)"  U  F  o  R(Y)  (see  comment  below), 

and  l(n)"UF  d  (3Z)Q(Z)v(-(3Z)Q(Z) a-L( Y)) 

(subgoals  (iii)  and  (iv)). 

4.  C3Z)Q(Z){C}Q(Y)  Sy  RO, 

5.  -’(3Z)Q(Z)a-'L(Y){C}->L(Y)  by  RO, 

6.  (3Z)Q(Z)vH3Z)Q(Z)a->L(Y)){C}Q(Y)v--L(Y)  by  OR-lemma,  4,5, 

7.  l(n)"{C}Q(Y)v-L(Y)  by  consequence  Rl, 

8.  Q(Y)AL(Y){p(R);C}Q(Y)v-'L(Y)  by  composition  R2,3,7, 
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9.  Q{Y){WHILE  L  DO  p(R);C}G  by  iteration,  8, 

10.  l(n){p(P);Y<-S;WHILE  L  DO  p(R),C}l(n+l)  by  R2,R3, 1,2,9 

where  l(n+l)  =  lnv(S,l(n)) 


Finally,  A(n+1)  =  A(n);  p(P);  Y<-S;  WHILE  L  DO  p(R);C;  so  that  l{A(n+l)}l(n+l).  Since  SUF 
d  G  is  assumed  true  and  G  =  G(n+1)AG’,  it  follows  that  l(n+l)UF=>G(n+l). 

COMMENT:  Step  3  above  is  justified  by  a  second  induction,  L(F)||-Q(Y)aL(Y){p(R)}R(Y), 
namely  that  programs  constructed  without  using  iterative  rules  are  correct.  This 
follows  from  the  proof  for  the  simplified  case  (Section  2.5),  since  the  variables  in  the 
goal,  R(Y)  are  required  to  occur  in  the  initial  state,  Q(Y)  a  L(Y). 

The  extension  of  the  proof  for  more  than  one  iterative  rule  is  similar. 


6.5  AN  EXAMPLE:  As  an  example  of  "while"  loop  generation  consider  the  task  of 
generating  a  program  to  compute  the  value  of  n  factorial  for  some  positive  integer  n 
where  multiplication  is  not  a  primitive  operation  but  is  done  by  repeated  addition.  The 
Frame  for  this  problem  is  shown  in  figt  11.  Also  used  is  the  primitive  procedure  for 
assignment  used  in  the  example  in  r  .ion  3.  To  achieve  the  goal  "FACT(X0,N)"  the 
system  applies  the  iterative  rule  TrACT.  The  premises  are  achieved  according  to 
Section  6.1  which  results  in  an  application  of  another  iterative  rule  TPROD.  The 
premises  of  TPROD  are  achieved,  the  "inner"  loop  assembled  and  optimized  and  state  is 
updated  with  respect  to  the  output  assertion.  The  assembled  while  loop  is  appended 
to  the  iteration  step  program  for  TFACT.  The  "outer"  loop  is  then  assembled  and 
optim^ed  and  the  state  further  updated  reflecting  the  total  state  transformation  of  an 
execution  of  the  nested  loop  program. 

The  output  program  after  optimization  with  statements  labeled  according  to  their  source 
of  generaton  in  the  algorithm  is  shown  in  figure  12.  Note  that  successive  values  of  the 
loop  variables  (called  "UPDATE  ASSIGNMENTS")  are  obtained  by  simple  assignment 
statements  rather  than  by  conditional  assignment  as  described  in  the  algorithm.  This  is 
the  result  of  applying  system  heuristics  which  are  able  to  use  the  arithmetic  operations 
PLUS  and  ADD1  which  are  primitive  functions  in  the  frame,  to  replace  the  conditional 
assignments. 
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KE1ATIONS 


DEFINITION 


UNIQUENESS 


VFACT  X,Y' 

"The  value  of  V  factorial  is  X" 

TRUE 

FALSE 

VFACT (  1  , » ) 

CX.Y) 

"The  contents  of  variable  X  is  Y" 

TRUE 

FALSE 

c(x,  0 

FACT  X.Yl 

"The  variable  X  contains  Y  factorial" 

TRUE 

FALSE 

FACT  ( X , ' ) 

VPR01H1CT  X.Y.Zl 

"X  is  equal  to  the  product  of  Y  and  Z" 

TRUE 

FALSE 

FALSE 

INTEGER  XI 

"X  is  an  integer" 

FALSE 

FALSE 

FALSE 

IS VAR  X  ■ 

"X  is  a  variable" 

FALSE 

FALSE 

FALSE 

NKWVAR  X' 

"X  is  a  new  local  variable" 

TRUE 

FALSE 

FALSE 

=  x,v 

"X  equals  Y" 

TRUE 

FALSE 

FALSE 

«  <-*  *  1  *  *-*  -4-*  *  «*>• 

H  *-**<•**  #  if-*  ik  •  *  * 

AXIOM 

ANTECEDENT 

CONSEQUENCE 

f  =  (V9,l)A=(Vl<5,l)l 

V  VFACT.  (DIV  V')  viO),(SUBl  VIO'); 

[  =  (V5,0)A=(VC,O)) 

V  VPRODUCT( (MINUS  V5 ,V3) , (SUB1  VC),VJ)  i 

SIMPLIFICATION  RULES 

(AUDI  (  SUlil  .X))  -y  X 
(SUBl(ADDI  X))  ->  X 
(MlNUSf  PLUS  X  Y)Y)  ->  X 
(D1  V( PKOD  X  Y)Y)  -.X 


VFACT(V9,V10)i 

vproduct(V5,v6,V3) 


FUNCTION  OUTPUT  SYNTAX 
(AUDI  X)  =  (X  +  I) 

(sum  x)  =  (x  -  i) 

( PLUS  X  Y)  =  (X  +  Y) 


Figure  11a 
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ITERATIVE  RULES 


RULE  NAME 

T  FACT 

TPROD 

BASIS  CONDITION 

NEW  VAR  '  V'  )A  INTEGER'  V\  ) 

AVI'ACT,  V5,Vi_  )AC(Vji,V5) 
ac(V7,v6); 

NEWVAR(V).  )AC  V).  ,0) 
AC(VI,0); 

INVARIANT 

C'V',V10)ACi'V;3,V9) 

AVFACT(V  ),V10) ; 

C(V4,V.')AC(V1,V!>) 
AVPRODUCr(V5,V6,VJ) ; 

ITERATION  STEP 

C  V/ ,  (ADI)l  Vlp))A 

P  RODUCT  ( Vjj  ,  Vh  ,  (ADD  1  V1C3) ) ; 

C  (  V'l. ,  (ADD1  Vb)) 

C( VI, (PLUS  V5,V5))J 

GOAL 

PACT  (Vi),  Vi.)  ; 

PRonuc'r(vi,vr’  ,v$) ; 

TEST 

-i=i'V10,Vi.) ; 

-1=(V6,V3) ; 

OUTPUT  ASSERTION 

C  V;  ,  (FAC  Vh))\ 

c ( VI , ( PROD  V2.V3)); 

/■  k-  +*•»(•  v  * *  -x- *•  *  *  y  *  <•  *  *x-  >  x  **•*■*•«  x- 

Figure  lib 
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PROCl (X0  N) 

ISVAR(X^) ; INTEGER(N) ; 


COMMENT 


INPUT  ASSERTIONS: 


p(P) (TFACT) - 

Initial  Assignment- 
(TFACT) 


OUTPUT  ASSERTIONS: 


C(X0  (FAC  N)) ; 


BEGIN 


y4  -  l; 

WHILE  -1=  (Y4  N)  DO 


BEGIN 


p  (P)  (TPROD)  (Optimized  Out)-^^  Y4  -  (Y4  +  1); 

rvi  -  0; 


Initial  Assignment  (TPROD V.TL*  •-  P» 


p^R)  (TPROD) _ _ _ _ 

UPDATE  Assignments  (TPROD 
(Optimized  Out) 

UPDATE  Assignment  (TFACT)- 


WHILE  -i=  (Y1  X0)  DO 


BEGIN 


Y2  -  (YS  +  Y4); 
Yl  -  (Y1  +  l); 


X0  -  Y2 ; 


p(R) (tfact) 


Figure  12, 
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The  complexity  of  programs  that  can  be  generated  using  the  system  is  increased  by 
some  simple  facilities  described  in  this  section.  The  capabilities  discussed  here  are 
incremental  extension  of  a  current  program,  use  of  a  program  library,  and  expansion  of 
assumptions. 


Tha  system  enables  a  user  to  plan  incremental  extensions  of  a  program  simply  by 
saving  each  competed  program  segment  A  and  its  output  state  0  in  a  stack.  The  user 
may  then  pose  a  new  goal  G  and  solve  the  problem  0{B}G.  The  composition  A;B  will 
then  be  output.  He  may  choose  to  start  from  any  previously  saved  state  and 

associated  program  segment. 


7  1  PIT  i  <AM  LIBRARY  When  a  program  A  has  been  generated  to  solve  P{A}Q,  the  user 
may  request  that  it  be  "generalized"  and  filed  in  the  program  library  where  it  may  be 
accessed  by  the  subgoaler  (similar  use  of  a  library  in  robot  planning  is  reported  in 
[Fikes.Hart,  and  Nilsson  1972]). 


Generalization  is  a  process  which  constructs  a  procedure  declaration  for  the  library  as 
foi  ows  Let  I  and  0  be  the  input-output  assertions  computed  for  A  during  its 
construction.  We  assume  P=>l,  0=Qa0’,  and  l{A}0.  The  non-fluent  conjuncts  of  I  are 
taken  as  the  type  declarations,  their  variables  being  the  parameters  of  the  new 
procedure.  These  actual  parameters  are  replaced  throughout  l{A}0  by  new  formal 
parameter  variables.  An  entry  of  the  form: 


((<procname>  <goal>  <effects>  <type  conditions>  <state  condition>)<body>) 


is  made  in  the  library,  where  <procname>  is  a  name  and  parameter  list,  <goal>  is  Q, 
<effects>  is  O’,  <body>  is  A,  and  it  is  assumed  that 


:type  conditions>  a  <state  condition>{<procname>}<goal>  a  <effects> 


Library  procedures  are  used  during  program  generation  by  matching  on  the  <goal>  then 
establishing  the  <type  conditions>  and  <state  conditions>  as  subgoals  in  that  order.  If 
The  conditions  are  satisfied  then  the  instantiated  <body>  is  included  in  the  program. 
There  is  no  attempt  to  organize  the  library  for  efficient  selection;  the  system  merely 
tries  all  library  procedures  before  any  frame  rule. 


As  an  example  of  program  assembly  using  the  library  consider  the  task  of  building  a 
*ower  toTeach  an  object,  i.e.  achieve  "HAS(M,B)".  Use  will  be  made  of  a  library 
program  to  find  and  put  on  shoes  which  achieves  WEARING(M, SHOES),  previously 
generated  using  the  same  Frame.  The  generated  program  is  then  extended 
interactively  by  posing  a  new  goal,  AT(M,P). 


A  robotics  Frame  for  this  problem  is  shown  in  Figure  13,  and  the  generated  programs  in 
Figure  14. 
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DEFINITION 

FLUENT 

PARTIAL 

UNIQUENESS 

KOrtOT  X' 

"X  Is  a  robot" 

FALSE 

FALSE 

FALSE 

IIOX  XI 

"X  is  a  box" 

FALSE 

FALSE 

FALSE 

AT  X.Y' 

"X  is  .It  location  Y" 

TRUE 

FALSE 

AT  X, •) 

OX  X.Y' 

"X  Is  on  Y" 

TRUE 

FALSE 

ON  X, •) 

MAS  X.Y' 

"X  has  possession  of  Y" 

TRUE 

FALSE 

FALSE 

STACKED  X.Y  .2' 

"X  is  stacked  on  Y  at  location  Z" 

TRIE 

FALSE 

FALSE 

IXSTACK  X.Y' 

"X  is  in  a  stack  at  location  Y" 

TRUE 

FALSE 

INSTACK  X," 

STACKHE I CUT  X.Y' 

"the  stack  height  at  location 

Y  is  X" 

TRUE 

FALSE 

oiACKHElGHT 

HEIGHT  X.Y* 

"X  is  positioned  at  a  height 
of  Y" 

TRUE 

FALSE 

HEIGHT  X,*) 

TOP  X.Y' 

"X  is  the  top  object  in  stack 
at  Y" 

TRUE 

FALSE 

TOP  *  ,Y  ) 

HI  EXIT  X.Y,  2' 

"X  is  as  high  as  Y  at  Z" 

TRUE 

FALSE 

FALSE 

HOLDING  X.Y. 2' 

"X  is  holding  Y  at  location  Z" 

TRUE 

FALSE 

HOLDING  X, * , 

CHAIR  X' 

"X  is  a  chair" 

FALSE 

FALSE 

FALSE 

CLOTHES  X' 

"X  is  an  article  of  clothing" 

FALSE 

FALSE 

FALSE 

CNDER  X.Y' 

"X  is  under  Y" 

TRUE 

TRUE 

FALSE 

HEARING  X.Y' 

"X  is  rearing  clothing  Y" 

TRUE 

FALSE 

FALSE 

FOOD  X,"' 

"X  found  Y" 

TRUE 

FALSE 

FALSE 

-  X.Y^ 

"X  is  equal  to  Y" 

FALSE 

FALSE 

FALSE 

A BOYER  X.Y. 7 

"object  X  is  above  robot  Y  at  Z" 

TRUE 

FALSE 

FALSE 

a  U'-i  y.  . 

"object  X  is  above  object  Y  it  7" 

TRUE 

FALSE 

FALSE 

u»rri>Mi*ox  s.' 

is  the  hot  t  on  box  at  Y" 

TRUE 

FALSE 

FALSE 

xrnOMHOXt'  X.Y. 2 

"X  is  the  hot  ton  box  at  under  Y" 

TRUE 

FALSE 

FALSE 

SKIjCNCR  X.Y. 

"object  X  is  below  robot  Y  at 

TRUE 

iALSE 

FALSE 

'IfLlH:  X.Y. Z 

"object  X  is  below  object  Y  at  Z" 

TRUE 

FALSE 

FALSE 

S*  PPI.Y  X 

"the  supplv  is  at  location  X" 

FALSE 

FALSE 

FALSE 

.KXTIinX  X.Y 

">;  is  the  next  hox  after  Y" 

TRUE 

FALSE 

FALSE 

Figure  13a 
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PRIM  IT IVK  PROCEDURE 


PRE-CONDITIONS 


POST-CONDITIONS 


t rave  I  ( Rl ,L1 ,L?) 

"Kl  travels  Irom  LI  to  1.  ” 


R0I10T  R1)MT(R1  ,L1  )AHEIGHT  (R1  ,j6) ; 


move (R 1,01 , LI ,L? ) 

"Kl  moves  01  from  LI  to  I.0" 


ROBOT  (R1  )A BOX  ( 01 ) AAT  (01  ,L1  )A  — »  INSTACK  ( 01 ,  LI  )A 
CLOTHES  (03  )AWEAR  I NG (R 1 ,03  )aAT  (R1  ,L1 ); 


AT  (R  1,1.-  ) ; 

AT(01,I^)aAT(R1,L.  ); 


stack  Rl ,0? ,01 ,L11 

"R1  stacks  OP  on  01  at  LI" 


climb  R1.01.L11 

"Rl  cl  I  mbs  01  at  1,1 " 


unc  limb  Rl  ,QP  ,  1.11 

"Rl  unc limbs  OP  at  LI" 


reach  Rl ,01  ,L1) 

"Rl  reaches  01  at  LI1 


lilt  Kl ,01 , LI ) 

"Rl  lifts  01  at  Ll" 


find  Rl ,01 , L 1 1 

"Rl  finds  01  at  Ll" 


put  on  Rl.Ol) 

"Rl  puts  on  01" 


AXIOM 


TAItOVKR 
TAHOVL 
Till:  EUR 
r UK LOW 
T  HOT 
TROTH 


I  NEXT 
T INSTACK 


DLI  I  NIT  ION 
ITIITL 


RO  HOT  R 1 )  A  BOX  ( 0 1 1  AI10X  { OP )  ( 0 1 ,  OP  1 A  AT  ( 0 1 ,  L 1 )  A 

AT{ OP  , Ll  )AAT ( R 1 , Ll  )AIIOLD  ING ( Rl  ,00  ,  L 1  )a 
HE  I GIIT  (R 1 , 3)A0N  ( R 1 ,01  ,L1  )a-STACKED  [03 ,01 ,  Ll ) 
ASTACKIIEIGIIT(H1,I  1); 


STACKED (OP ,01,L1)A 
STACKHEIGHT,  (EVN(ADI)l  III ) )  ,L1 
ATOP (01, Ll) | 


ROBOT  Rl  )AA HOVER  (01  ,Rl  .1.1  )AAT  ( Rl ,  Ll  )A 
-iINSTACK(Ol,Ll)v 

{ STACKED  (01, OP,  Ll)A0N(Rl,O'’,Ll)jA 
REQUEST  (HEIGHT  (Rl  .111 ) )  ; 


0NiR1,01,L1)a 
IIEIGHT(R1,  (KVN(ADI)l  111))); 


R0B0T(R1)ABEL0WR  (01 ,  Rl  ,L1  )AAT(R1  ,L1  )A 
REQUEST  (HE  IGHT  ( R 1 ,  II 1 ))  A 
REQUEST  ( STACKED  (OP  ,01 ,  Ll )  )A 
ON(Rl.OP.Ll); 


0N( Rl ,01 , Ll IA 

HE  1GIIT  (Rl ,  (EVN  (SUlil  III))); 


stepo  1  f (Rl ,01 , Ll ) 

"Rl  steps  off  01  at  Ll" 


=  (ll  1  ,j6 )AHE IGIIT ( R 1 , 1 ) AON ( R 1 ,01 , Ll ) ; 


IILIGIIT(R1,II1)A 
~0N(R1, 01,1.1); 


ROBOT  Rl )AAT ( 01 ,L1 )AH 1ENUF (Rl ,01 , Ll ) ; 


R0B0T(R1)AB0X(01)AAT(01,L1)AAT(R1,L1)a 
-i|NSTACK(01,Ll) ; 


ROBOT  (Rl  )ACHA  IR(  OP  )AAT (OP  ,  Ll )  AAT(R  1 ,  Ll ) A 
UNDER (01, 0'.' ) ; 


ROBOT (Rl)ACLOTHES (Ol)AFOUND(Rl ,01) ; 


HAS  Rl ,01) ; 
II0LDINC(R1, 01,1,1); 
FOUND (Rl,01); 
WEARING (Rl ,01 ) ; 


ANTECEDENT 


CONSEQUENCE 


-ON  Rl.o  IN  Rl, 03, 1.1)AAB0VE(01, 03,1.1))  ;  ABOVKR  (01  ,R1  ,1,1 1 ; 

=  ,0l,0.  ED  0P,03,l.l)AAB0VE(01,a5,Ll)}  ;  ABOVE(01 ,03 , Ll ) ; 

on  Ri,a3,Li)ABi:i.ow;oi,a  ,1,1)5  belowroi.ri ,1.1) ; 

=  (01,03)'.  (STACKED  03,0  ,1.1  lABELOW  ,01  ,0P  ,1,1 1)  ;  BELOW  01 ,03  ,  Mi ; 


T0P(0;  ,I,llAB0TT0Mll0XU(01 ,03,1.1); 


STACKED1  OJ, Oli  ,l,l)ASTACKED(0'i  ,0P,l.l)v 
STACKED ( 03.01.Ll) ATSTACKED (Ok , CP  ,1,1  )v 
BOTTOMBOXU  (01 , Of*  ,1,1)  ; 


BOTTOMBOX  ( 0 1 , 1. 1 )  ; 
BOTTOMBOXU ( 01 , 03 , Ll ) ; 


SUPPLY  (Ll  )AAT  (Oh  ,1,1) ; 
TOP(02,L1)ABELOW(01,OP,L1)  ; 


NEXT BOX  (0*1  ,03) ; 
INSTACK(Ol.l.l); 


HE  IGIIT  (01  ,H1  lASTACKIIE  I  GIIT  (111  ,L1  )ATOP(OP  ,1.1  )A0N(R1  ,Q.  ,L1)  =  II I ENUF  (  R 1 , 01 ,  Ll ) 


Figure  13b 
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OUTPUT 


ITERATION  STEP 


INVARIANT 


ITERATIVE  RUl.i;  BASIS  CONDITION 


ON  Rl,01,Ll)A 
STACKED (OP ,01 ,L1) 
VT0P(01 ,L1) ; 


REQUEST  llEinHTfRl.il. 
AGZ  TIE  )v 

l. BOTTOM BOX  0;.,U) 
AON'Kl.OT.LlIJ ; 


on  ki,oi,i.i;a 

STACKED  01,0  ’ ,1.1) 
vBOTTOMBOX  01, LI) 


nz(ni).' 

REQUEST  HEIGHT  Rl.II  )) 
ACT  II.'  .Ill) ; 


HOLD  INC  (1(1  ,C<>  ,1.1  1  STACKIIE I  (HIT 
MIEIGIIT'Rl  ,11  )  Hl.l.l); 

ASTACKED'OL  ,0J,L1  ; 


TOP  O  ,1.1  ’(A 
STACKIIE  I GIIT 
IP,L1)A 
NEXT BOX  OL  ,0; 


STACKED  O:  ,01 ,1.1 
AON  Rl.or  ,1,1), 


INITIAL  STATE 


ROBOT  Ml  A  RON  IIPlAHOX  B  •  'A  BOX  B’’  'ABOX.  B')AliOX  !V>  VUIOX  B  '  )AAT  ,M,P)AAT  B,U)AAT  IT  ,SLOC)AAT(  IT  ,S1.0C)AAT  K),  ,SLOC). 
AT  IT  ,SLOC.).\AT  lUi  .SLOClMT  IT  ,SLOC)ASUPPI,Y'  SLOC)ASTACKIIEIGI1T(0,H)AIIE1CIIT(H,C!)AHEIGIITi  B.U  JACLOTHES (SHOES )A 
CHAIR  CIIAIRDaCHAIR  CHAIR’)V\T  SHOES  ,  CORNER  )AAT  ( CIIA IR1  .CORNER  )AAT  CHAIR.  .CORNER); 


ADVICE 


PAIRWISE  INKQUA'  ITIES :  travel  Rl ,  * ,  • )  ,move(Rl ,01 
STACK, Rl ,  ' ,  *  ,1.1) 


NEPERS  I  VE  RULES  ;  CLIMB,  TABOVE  .THE  LOW  ,  TWITE 


Figure  13c 
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PRor.i  (m  shoes) 

ROBOT  M'jCHAIH  CHAIR. )  ;  CLOTHES  SHOES)  ; 

COMMENT 

INPUT  ASSERTION: 

HEIGHT  M  ■)  'AAT.M  P)AAT  CHAIR'-  CORNER) 

OUTPUT  ASSERTION: 

AT  M  CORNER)  A  ROUND  M  SHOES  )AWEARINC(M  SHOES); 
COMMENT 

PROcr  ArFKMlTS_TO_ACIllEVE_  i  FOUND  M  SHOES)  ; 
IIEC.IN 

TRAVEL, M  P  CORNER); 

IF -UNDER- SHOES  CHAIR.  )  THEN 
PROUD  M  SHOES) 

ELSE 

BEGIN 

FIND  H  SHOES  CORNER 
END 

PLT_ON  M  SHOES) 

END 


procj  I  M  li) 

ROBOT; M' ; BOX .BY  !  ;CL0THES(  SHOES),CHA  I  R(CHA  IK.' )  ;H0X  (llA  )  ;SUPPLY(KI.OC) ;  BOX  f  Bf  ■ ) ;  IIOX(Bi) ; 
COMMENT 

INPUT  ASSERTION: 

AT  M~P)AAT  B'  SL0C)A1IEICHT(M  0  )  AAT 'CHAIR.  CORNER )AAT l BA  SLOC) 

AllEIGHT  II  li  )ASTACKHEK.irr(0  U ) aAT  1)6  SLOC  )aAT(  115  SLOC) 

OUTPUT_ASSERTION : 

AT(M  P)A AT ( B 7  IDAATfBi  II)ASTACKED(B4  B7  D)AAT(Bf)  U) 
aSTACKED(B6  BA  U )  a  STACKIl  R I  GOT  ( A  ll)MIAS(M  H)  A  HEIGHT  (M  H) 

AKOUM)  M, SHOES  )AWEAR  !NC(M. SHOES ) ;  AAT  (  B5  U)  /-STACKEDf  BJ  1)6  U)  ; 

BEGIN 

TRAVEL- ;M  P- CORNER) ; 

IF- UNDER  SHOES  CHAIR.  )  THEN 
Assembled  PROUD fM  SHOES) 

I  rom  _ ^  Kl.SK 

Mhrary  BIX  IN 

FIND  M  SHOES  CORNER) 

end 

pirr_0N  m  shoes  ) 
rRAftl'M  Corner  si.oc); 

MOVE  M  B  SLOC  U); 

TRAVEL  M  U  SLOC' ; 

MOVE  M  IV.  SLOC  C  : 

LIFT  M  IV.  II); 

CLIMB  M  I)  D'; 

STACK  M  1)1.  B-  U)  ; 

CLIMB' M  BA  U); 

v '  -  ; 

YA  -  IV.  ; 

IK  NEXT  BOX i WA  YA )  THEN 
■/.;  -  UA  ; 

WHILE  -STACKHEIGHTI  A  U)  DO 
BEGIN 

i.  •  -  add  l 1  y;  ) ; 

Y1  -  YA  ; 

IP  STACKED  YI  W1  U)  THEN 
71  -  W1  ; 

WHILE -HEIGHT  Ml  DO 
BEGIN 

UNCLIMB  M  YL  U); 

Yl  -  XI ; 

IF  STACKED  Yl  WI  U)  THEN 
Zl  -  Wl ; 

END 

SIKPOFF  M  II  U); 

TRAVEL  M  U  SLOC); 

MOVE  M  /.A  SLOC  U); 


Figure  14a 
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1,1  FT (M  Z1*  *>); 

CLIMB (M  BY  U); 
y:  -  BY  1 

IF  STACKED  VK  Y"  U  1  THI 

r  -  wr ; 

WHILE  — iHE  l  CHIT ■  M  Y?  '  DO 
BEG  1  N 

CLIMB(M  X.  UV, 

Y?  -  '!■'<  \ 

IF  STACKED  W  YP  l>) 

z:  -  w:  ; 

END 

STACK  M  ZB  YU  U) ; 


NEXTBOX  W>I  YE)  THEN 


CLIMB  >1  BJ  1 
REACH  M  B  V 


IF  STACKED  Y5  WB  l')  THEN 
V:  -  W> ; 

WHILE -'HEIGHT  (M  l  U)  DO 
BEGIN 

UNCLIMB (M  Y'j  U)J 
IF  STACKED  Y5  W‘j  U)  THEN 


1 ncremental 
Extens Ion 


END 

STEl’OFE  M  IV  i 
TBAVEL  H  U  1’) 
END 
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7.2  EXPANSION  OF  ASSUMPTIONS:  A  basic  capability  for  structuring  programs  is 
provided  by  interactively  allowing  the  user  at  any  level  in  program  generation  to  define 
a  primitive  procedure,  P{p}Q,  as  an  assumption.  The  program  generator  will  then  use  p 
as  usual  except  at  each  point  of  call  to  p  in  the  program  the  current  state  I’  and 
current  goal  G  will  be  saved.  The  triple  <p,l\G>  is  placed  in  a  stack  of  subtasks  for 
later  expansion. 

When  a  program  containing  assumed  primitive  procedures  has  been  generated,  the  user 
is  given  the  list  of  assumptions  his  program  depends  on  and  allowed  to  selectively 
expand  them  in  terms  of  lower  level  procedures.  For  the  subtask  <p,l\G>,  the  state  is 
initialized  to  I’,  the  frame  may  be  changed,  G  is  given  as  the  goal, and  a  body  for  the 
procedure  p  is  generated. 

Consider  the  example  given  in  Section  6  of  computing  the  value  of  n  factorial  where 
multiplication  is  not  a  primitive  operation.  The  initial  frame  is  the  same  except  that  in 
place  of  an  iterative  rule  for  multiplication,  there  is  an  assumed  primitive  procedure 
ISVAR(  V  l){times<  V 1  ,V2,V3)  }PR0DUCT{  V 1  ,V2,V3), 
where  PR0DUCT(V1,V2,V3)=C(V1,(PR0D  V2.V3)). 


The  program  generated  using  this  frame  is  given  in  Figure  15.  To  expand  the  non¬ 
primitive  procedure  "timesfVlA^.VS)"  the  full  frame  including  the  iterative  product  rule 
is  given  and  the  sub-program  generated  is  shown  in  Figure  1C. 

In  the  current  implementation  it  is  assumed  that  the  expanded  sub-programs  will  have 
no  side  effects.  However  this  assumption  could  be  removed  by  a  mechanism  similar  to 
checking  rejoin  conditions  for  contingency  programs  (Section  5.4). 

To  develop  a  useful  structured  programming  system  interaction  appears  essential  along 
with  further  study  about  how  humans  do  (or  should  do)  programming. 
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PROCKXO  N) 

1SVAR  XO) ; INTEGER  N); 
COMMENT 

INPUT  ASSERTION: 


NONE 

OUTPUT  ASSERTION: 

C:X<5  (FAC  N))i 
COMMENT 

THIS  PROGRAM  RELIES  ON  T  IF. 
(TIMES'! 

BEGIN 
XO  -  I  I 
Y 1  -  I  | 

WHILE  >  VI  N)  1)0 


BEGIN 

yi  -  Yi+1; 

TIMES. XO  XO  Yl) 
END 


END 


FOLLOW I NG  ASS  UMPT IONS 


Figure  15 


TIMES  f.\6  Yl  XI) 
ISVAR(XO) I 
COMMENT 

INPUT  ASSERTION: 
NONE 

OUTPUT  ASSERTION; 
ClXO  (PROD  Yl  Zl))i 
BEGIN 


1  •“  • 

WHILE  ”>  =  Y  Yl  DO 
BEGIN 

Y  -  Y  +1 ; 

XO  -  XO+Z 1 ; 

END 

END 


Figure  16 


fcitfe»c<«tt(ia^abyA,j,.  .r>'rf.^,.r  ^'^-a^e^iiai^ayafe. a^asSA 
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APPENDIX  1  -  AN  INTERACTIVE  SESSION 


A  sample  interactive  session  is  here  presented  to  illustrate  the  system’s  use  in  frame 
definition  and  program  generation.  Statements  typed  by  the  user  will  always  be 
prompted  by  The  top  level  system  function  is  "SUBGOAL"  which  is  called  in  the 
manner  given  below  to  accept  a  frame  definition  from  the  terminal.  Comments  to  aid 
the  reader’s  understanding  of  the  dialogue  will  be  enclosed  in  quotes. 

*(SUBGOAL) 

"The  system  now  enters  an  interactive  mode  for  Frame  definition." 

*  *  *  *  SEMANTIC  FRAME  DEFINITION  *  *  *  * 

RULE  TYPE*  AXIOM 

RULE  NAME*  AONTOP 

IS  THIS  AN  ASSUMPTION?*  NIL 

IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 

INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 

PRECONDITIONS: 

*  ROBOT(Xl)  a  ON(Xl,X2)  a  nSTACKED{X3,X2); 

POSTCONDITIONS: 

*  ONTOP(Xl); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  STAND0N(R1,Z1) 

IS  THIS  AN  ASSUMPTION?*  NIL 
IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS: 

*  ROBOT(Rl)  a  ON(Rl,Wl)  a  BOX(Zl)  a  CLOTHES(Ol)  a  WEARING(Rl.Ol) 

A  AT(Z1,Y1>  a  AT(Rl.Yl); 

POSTCONDITIONS: 

*  QN(R1,Z1); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  DRESS(Rl.Ol) 

IS  THIS  AN  ASSUMPTION9*  T 
IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS: 

*  ROBOT(Rl)  a  CLOTHES(Ol); 

POSTCONDITIONS: 

*  WEARING(Rl.Ol); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  TRAVEL(R1,L1,L2) 

IS  THIS  AN  ASSUMPTION?*  NIL 

IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 

INEQUALITY  IN  ARGUMENT  POSITIONS*  (R !,*,*> 


PRECONDITIONS: 

*  ROBOT(Rl)  a  AT(R1,L1)  a  -  0N(R1,02,L1); 

POSTCONDITIONS: 

*  AT(R1,L2); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  STEPUP(X1,Y1,Z1) 

IS  THIS  AN  ASSUMPTION?*  NIL 

IS  THE  RULE  DIRECTLY  RECURSIVE?*  NIL 

INEQUALITIES  IN  ARGUMENT  POSITIONS*  (Rl,*,*) 

PRECONDITIONS: 

*  BOX(Zl)  a  ROBOT(Xl)  a  STACKED(Zl.Yl)  a  0N(X1,Y1); 
POSTCONDITIONS: 

*  0N(X1,Z1); 

RULE  TYPE*  ITERATIVE 
RULE  NAME*  ITONTOP 
IS  THIS  RULE  DIRECTLY  RECURSIVE?*  NIL 
BASIS  CONDITION: 

*  ROBOT(Xl)  a  ON(Xl,X2); 

INVARIANT: 

*  ON(Xl,X3)  a  STACKED(X4,X3)i 
ITERATION  STEP  CONDITION: 

*  0N(X1,X4); 

CONTROL  TEST*  NIL 
OUTPUT  ASSERTION*  NIL 
GOAL*  ONTOP(Xl); 

RULE  TYPE*  NIL 

INITIAL  STATE: 

*  AT(M.CORNER)  a  AT(B1,L)  a  STACKED(B3,B2)  a  STACKED(B2,B1) 
a  BOX(B3)  a  BOX(B2)  a  B0X(B4)  a  STACKED(B4,B3)  a  BOX(Bl) 

a  ROBOT(M)  a  CLOTHES( SHOES); 

SEMANTIC  PROPERTIES  OF  RELATIONS: 

IS  ROBOT(Rl)  A  FUNCTION  OF  THE  STATE?*  NIL 
IS  ROBOT(Rl)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  AT(R1,L1)  A  FUNCTION  OF  THE  STATE?*  T 

IS  AT(R1, LI)  PARTIAL?*  NIL 

ARGUMENT  UNIQUENESS  PROPERTIES*  (Rl,*) 

IS  STACKED(X4,X3)  A  FUNCTION  OF  THE  STATE?*  T 
IS  STACKED(X4,X3)  PARTIAL?*  NIL 
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ARGUMENT  UNIQUENESS  PROPERTIES*  (X4,*) 

IS  BOX(Zl)  A  FUNCTION  OF  THE  STATE?*  NIL 

IS  BOX(Zl)  PARTIAL?*  NIL 

ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  ONTOP(Xl)  A  FUNCTION  OF  THE  STATE?*  T 
IS  ONTOP(Xl)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  CLOTHES(Ol)  A  FUNCTION  OF  THE  STATE?*  NIL 
IS  CLOTHES(Ol)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  WEARING(Rl.Ol)  A  FUNCTION  OF  THE  STATE?*  T 
IS  WEARING(R1 ,0 1 )  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  0N(X!,Z1)  A  FUNCTION  OF  THE  STATE?*  T 

IS  ON(Xl.Zl)  PARTIAL?*  NIL 

ARGUMENT  UNIQUENESS  PROPERTIES*  (XI,*) 

FILENAME*  DSK:PCLI 
TRACE  MODE?*  T 
PERFORMANCE  STATISTICS?*  T 
LOOKAHEAD?*  NIL 
ALGEBRAIC  SIMPLIFICATION?*  NIL 

SUBGOALING  SYSTEM  GENERATED!!! 

"A  subgoaling  system  corresponding  to  the  Frame  has  now  been  generated 
and  the  system  may  now  receive  a  goal  to  achieve," 

SUBMIT  GOAL*  ONTOP(M) 

DO  YOU  WANT  THE  PROGRAM  LIBRARY?*  NIL 
DO  YOU  HAVE  ANY  ADVICE?*  T 
***  ENTERING  ADVICE  SYSEM  *** 

1*  TRY  STANDON  BEFORE  STEPUP 

2*  NIL  "Exit  advice  system  and  begin  program  generation." 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— ITONTOP 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ON  M  X2))STAND0N 

RULES  ENTERED  AND  GOALS  PEND'NG  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ON  M  X2))(STAND0N(  WEARING  M  SHOES))DRESS 


((DRESS  M  SHOES))  ,  .  ...  ,  .. 

"Current  program  segment  generated  is  displayed  in  this  form. 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ON  M  X2))(STANDON(AT  M  L))TRAVEL 

((DRESS  M  SHOES)(TRAVEL  M  CORNER  L)) 

DRESS  M  SHOESKTRAVEL  M  CORNER  L)(S'I  ANDON  M  Bl) 

"This  constitutes  the  basis  program  for  the  iterative  rule. 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH. 
— (ITONTOP(ON  M  B2))STANDON 

STANDON  IS  FAILING!!! 

— (nON  M  Wl)  WAS  THE  LOSER  . 

"STANDON  is  only  applicable  for  climbing  from  ground  level. 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH. 
— (ITONTOP(ON  M  B2))STEPUP 

((STEP  M  Bl  B2)) 

"This  is  part  of  the  loop  body." 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— (ITONTOP(ONTOP  M))AONTOP 

"The  system  now  interpretively  updates  the  state  until  the  goal  is 
true,  then  the  while  loop  is  assembled." 

DO  YOU  WANT  TO  OPTIMIZE  THE  PROGRAM.'*  NIL 
IS  THIS  PLAN  USEFUL  ENOUGH  TO  GENERALIZE'*  T 
IS  THIS  A  PROCEDURE  WITHOUT  SIDE  EFFECTS?*  NIL 

THE  GOAL  (ONTOP  M)  IS  ATTAINABLE  BY  THE  FOLLOWING  PROGRAM: 
"The  desired  program  has  been  generated  and  will  now  be  displayed. 

RQBOT(  M)  ;CLOTHES(  SHOES);(BOX(B  1  );B0X(B  2)  i 

COMMENT 

INPUT  ASSERTIONS: 

AT(M  CORNER)  a  AT(B1  L)  a  STACKED(B2  Bl) 

OUTPUT  ASSERTIONS: 

WEARING(M  SHOES)  a  AT(M  L)  a  ONTOP(M); 

THIS  PROGRAM  RELIES  ON  THE  FOLLOWING  ASSUMPTIONS: 

(DRESS); 

BEGIN 

DRESS(M  SHOES); 


Et'aweata© 
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TRAVEKM  CORNER  L); 

STANDON(M  Bl); 

Y 1  -  Bl; 

IF  STACKED(W1  Yl)  THEN 
Z1  -  Wl; 

WHILE  -  ONTOP(M)  DO 
BEGIN 

STEPUP(M  Yl  Zl); 

Yl  -  Zl 

IF  $TACKED(W1  Yl)  THEN 
Zl  -  Wl; 

END 

END 

DO  YOU  WANT  TO  DO  STRUCTURED  PROGRAM  DEVELOPMENT?*  T 

TRYING— ((DRESS  M  SHOESXWEARING  M  SHOESXSTATl.AST)) 

"This  task  triple  consists  of  procedure  name,  goal  and  state." 

DO  YOU  HAVE  ANY  ADVICE?*  T 

***ENTERING  ADVICE  SYSTEM*** 

1*  ADD  PUT-ON 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  PUT-ON(Rl,OJ) 

IS  THIS  AN  ASSUMPTION9*  NIL 
IS  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS; 

*  ROBOT(Rl)  a  CLOTHES(Ol)  a  FOUND(R  1 ,0 1 ); 

POSTCONDITIONS: 

*WEARING(R1,01); 

RULE  TYPE*  PRIMITIVE  PROCEDURE 
RULE  NAME*  FIND(R1,01,L1) 

IS  THIS  AN  ASSUMPTION?*  NIL 
IS  RULE  DIRECTLY  RECURSIVE?*  NIL 
INEQUALITIES  IN  ARGUMENT  POSITIONS*  NIL 
PRECONDITIONS: 

*  ROBOT(Rl)  a  CHAIR(02)  a  AT(02,L1)  a  AT(R1,L1)  a  UNDER(01,02); 
POSTCONDITIONS: 

*  FOUND(Rl.Ol); 

RULE  TYPE*  NIL 


INITIAL  STATE: 
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*  CHAIR(CHAIRl)  a  CHAIR(CHAIR2)  a  AT(CHAIR1, CORNER) 
a  AT(CHAIR2, CORNER); 

SEMANTIC  PROPERTIES  OF  RELATIONS: 

IS  FOUND(Rl.Ol)  A  FUNCTION  OF  THE  STATE?*  T 
IS  F0UND(R1,0' )  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  CHAIR(02)  A  FUNCTION  OF  THE  STATE9*  NIL 
IS  CHAIR(02)  PARTIAL?*  NIL 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

IS  UNDER(01,02)  A  FUNCTION  OF  THE  STATE?*  T 
IS  UNDER(01,02)  PARTIAL?*  T 
ARGUMENT  UNIQUENESS  PROPERTIES*  NIL 

ALGEBRAIC  SIMPLIFICATION9*  NIL 

SUBGOALING  SYSTEM  GENERATED!!! 

"The  Frame  addition  has  now  been  translated" 

2*  DELETE  DRESS 
3*  NIL 

"Exit  Advice  system." 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 

— (PUT-ON(FOUND  M  SHOES))FIND 

((FIND  M  SHOES  CORNER)) 

((FOUNDER  SHOES  CHAIR  1)  THEN  (PROC2  M  SHOES) 

ELSE((FIND  M  SHOES  CORNER)))(PUT-ON  M  SHOES)) 

"The  conditional  statement  is  generated  since  it  is  not  known  where 
the  shoes  are." 

DO  YOU  WANT  TO  OPTIMIZE  THE  PROGRAM?*  NIL 
IS  THIS  PROGRAM  USEFUL  ENOUGH  TO  GENERALIZE?*  T 
IS  THIS  PROCEDURE  WITHOUT  SIDE  EFFECTS?*  NIL 

THE  GOAL  (WEARING  M  SHOES)  IS  ATTAINABLE  BY  THE  FOLLOWING  PROGRAM: 
"This  procedure  is  the  structured  expansion  of  the  non-primitive 
procedure  DRESS  called  in  PROC1," 

DRESS(M  SHOES) 

ROBOT(M);CLOTHES(SHOES);CHAIR(CHAIRl); 

COMMENT 
INPUT  ASSERTIONS: 
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AT(M  CORNER)  a  AT(CHAIR1  CORNER) 

OUTPUT  ASSERTIONS: 

WEARING(M  SHOES)  a  FOUND(M  SHOES)  a  WEARING(M  SHOES); 

COMMENT 

PROC2  ATTEMPTS  TO  ACHIEVE  FOUND(M  SHOES); 

BEGIN 

IF  --UNDER(SHOES  CHAIR1)  THEN 
PROC2(M  SHOES) 

ELSE 

BEGIN 

FIND(M  SHOES  CORNER); 

END 

PUT-ON(M  SHOES) 

END 

DO  YOU  WANT  TO  DO  CONTINGENCY  PLANNING?*  T 
WHAT  IS  YOUR  PREFERENCE? 

- IF  NONE  TYPE  NIL*  NIL 

TRYING— (PROC2  (FOUND  M  SHOES)(STAT2.CST)> 

"The  contingency  task  triple  consists  of  procedure  name,  goal  and  state," 

DO  YOU  HAVE  ANY  ADVICE?*  NIL 

RULES  ENTERED  AND  GOALS  PENDING  IN  CURRENT  SUBGOAL  TREE  PATH: 
— FIND 

((FIND  M  SHOES  CORNER)) 

DO  YOU  WANT  TO  OPTIMIZE  THIS  PROGRAM?*  NIL 
IS  THIS  PROGRAM  USEFUL  ENOUGH  TO  GENERALIZE?*  T 
IS  THIS  PROCEDURE  WITHOUT  SIDE  EFFECTS?*  NIL 

THE  GOAL  FOUND(M  SHOES)  IS  ATTAINABLE  BY  THE  FOLLOWING  PROGRAM: 

PROC2(M  SHOES) 

ROBOT(M);CHAIR(CHAIR2); 

COMMENT 
INPUT  ASSERTIONS: 

AT(CHAIR2  CORNER)  a  AT(M  CORNER) 

OUTPUT  ASSERTIONS: 

FOUND(M  SHOES); 

COMMENT 

PR0C3  ATTEMPTS  TO  ACHIEVE  FOUND(M  SHOES); 

BEGIN 

IF  -UNDER(SHOES  CHAIR2)  THEN 
PROC3(M  SHOES) 

ELSE 

BEGIN 


65 


APPENDIX 


F!ND(M  SHOES  CORNER); 

END 

□0EY0U  WANT  TO  DO  CONTINGENCY  PLANNING?*  NIL 
DO  YOU  WANT  TO  CONTINUE  FROM  THE  CURRENT  STATE?*  NIL 
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